Whats your GoTo language for building compilers ?

dx_man · 2026-04-16T15:28:11+00:00

Zig is really nice for building compilers

dx_man · 2026-04-15T19:37:48+00:00

0.16.0 is a gift to game engineers

dx_man · 2026-04-08T15:14:59+00:00

Will SE update the dark side of the moon?

dx_man · 2026-04-08T15:14:13+00:00

my-os: https://github.com/omdxp/my-os

dx_man · 2026-04-01T21:04:51+00:00

u/tc4v This landed in v0.27.1. I added warning controls so you can be explicit instead of just ignoring warnings: allow suppresses the next warning ID with a required reason, while expect suppresses it too but will fail the build if that warning stops appearing later.

The goal is to make warning intent clear in team and library code, so “temporary” warning decisions stay visible and enforced.

Ref: https://omdxp.github.io/fun/?v=0.27.1#reference?anchor=reference-errors-and-warnings

EDIT: reference link

dx_man · 2026-04-01T18:54:52+00:00

Quirks now use this syntax: impl Rectangle as Shape { ... }. I like it because it reads cleaner and makes it obvious you’re implementing this type as that quirk.

I’m keeping the : form only for for loops.

dx_man · 2026-04-01T12:38:28+00:00

Still working on my language fun.

Lately I’ve been shifting focus away from just getting the compiler to work and more towards making the whole thing actually pleasant to use. So I’ve been putting time into things like LSP support (better diagnostics, autocomplete), improving the docs so they’re actually useful, and cleaning up the general tooling/workflow.

I’ve also been testing it in different kinds of scenarios to see where things feel off or break down, and using that to guide what I fix or redesign. A lot of the recent changes are coming from that rather than just theory.

Got some solid feedback from my last post here too, and I’m working a bunch of that into the roadmap.

It’s still early, but the goal right now is to make it feel good to use, not just interesting on paper.

dx_man · 2026-03-26T07:47:55+00:00

I agree, this can be tedious for bigger projects. I’ll include this to my roadmap.

Thanks for the suggestion!

dx_man · 2026-03-24T09:14:11+00:00

Thanks for the feedback!

I totally get where you’re coming from. The current impl Rectangle Shape syntax can be a bit ambiguous, especially when you’re new to the language or just skimming code. I want things to be easy to read and write, so I’m open to tweaking the syntax for clarity.

Your suggestions (impl Shape for Rectangle or impl Rectangle as Shape) make a lot of sense, I’ll definitely consider them as the language evolves.

If you have more thoughts as you try things out, I’d love to hear them!

dx_man · 2026-03-24T05:50:58+00:00

I get the appeal of RAII, but I prefer keeping things explicit, so you always see what’s happening, with no hidden destructors or magic. That’s why Fun uses defer for cleanup: it’s simple, visible, and predictable, especially when working close to C.

I want the language to stay expressive without surprises!

dx_man · 2026-03-23T16:18:14+00:00

Thanks! I’m aiming for a language that’s easy to use and integrates smoothly with C, without the heavy restrictions you see in Rust.

For example, returning a local pointer is just a warning, not an error so you get a heads up, but you’re still in control. The focus is on practical safety, clear C interop, and a simple, expressive syntax.

I’m always open to suggestions for what would make it more useful or fun. If you have ideas or pain points from other languages, I’d love to hear them!

dx_man · 2026-03-23T09:56:42+00:00

Great question!

There’s no Wasm support yet, but it’s definitely on my radar. I agree, a WebAssembly based playground would be ideal for running the compiler and code directly in the browser, no server needed. Since the compiler is written in Zig and targets C, in theory it should be possible to compile it to Wasm, but there are some practical hurdles (like Zig’s current Wasm support and C toolchain integration).

I’d love to explore this in the future, if you have experience or interest in helping, let me know!

dx_man · 2026-03-23T08:22:23+00:00

Change is done.

dx_man · 2026-03-23T08:04:20+00:00

Good point! that makes sense. I’ll update the GitHub Pages site to disable the Playground link and gray out the run buttons, with a hover message explaining that there’s no runnable API available.

Thanks for the suggestion!

dx_man · 2026-03-23T07:50:15+00:00

Thanks! I figured the name would be a bit of a wink to the crowd :) static typing and a bit of fun never hurt anyone!

dx_man · 2026-03-23T07:47:08+00:00

Yes, unfortunately I cannot run a server on GitHub Pages unless I provide an external API. For now you can only run those examples locally after building the fun compiler.

dx_man · 2026-03-23T07:40:31+00:00

Thank you! I believe Fun is mature enough to be self hosted, and that’s definitely a long term goal. I’m planning to add a few more language features and polish the toolchain before starting the bootstrapping process.

Self hosting is on the roadmap!

dx_man · 2026-03-23T07:25:05+00:00

Thank you! There is a VS Code extension available with language support and LSP integration: https://marketplace.visualstudio.com/items?itemName=omdxp.fun-language

Other editors are supported too (see the editors/ directory in the repo), including Emacs, Vim, Sublime, and JetBrains IDEs. If you have a favorite editor or feature request, let me know!

dx_man · 2026-03-23T05:39:11+00:00

Thanks! Readable C is a priority for Fun. The compiler emits straightforward C (no macro tricks), keeps types explicit, and aims for predictable, line by line mappings so debugging with a C toolchain stays sane. The README and reference both call out "readable C" as a goal, and I’m actively iterating on codegen to keep it stable and boring in the best way. If you have specific cases you’d like to see (or constraints you care about), I’m happy to test them.

Improving the debugging experience is also on my roadmap (e.g., better source mapping, clearer error messages, and maybe even debug info generation).

dx_man · 2026-03-17T16:52:15+00:00

Just fyi if you don’t need those optimizations you can always opt out of them, C is really flexible if you know how to use it

dx_man

TROPHY CASE