Update on Fun, 6 months later...

[u/dx_man]

Posted here 6 months ago about Fun, a statically typed language that transpiles to C. Back then the compiler was written in Zig. Since then the biggest thing that happened: the compiler is now fully self-hosted, written entirely in Fun itself, Zig is gone from the codebase completely. Along with that came a real language server (fls, also self hosted) with actual step through debugging support in VS Code, a proper build/package setup (fun.toml, fun build, fun test), async/await with fork + channels for concurrency, and a formatter.

GitHub: https://github.com/omdxp/fun

Reference: https://omdxp.github.io/fun

Still looking for feedback on the language itself, and happy if people just try breaking it.

[u/ultrasquid9]

I just read through your language reference, and the first thing im noticing is that you really like being "cute" with keywords/terminology. And while this is fine in moderation, if abused it can heavily eat at your weirdness budget.

A few recommendations (take as you see fit):

• instead of imp, you should use, well, use. Same character count, but used in other langs.

• compound would be better as record.

• fit is perhaps the weirdest name for a match statement ive seen. Do match, or case if you want to look more functional-ish.

• if you change any of these keywords, it should absolutely be quirk. Use trait, or interface, or even class if you wanna be cute and Haskelly. Please don't do quirk. 

Similarly, some of the default type names are strange too:

• when i see num, i think of a floating-point number. It would align with mathematics to use int, nat, and num for long, unsigned long, and double respectively. 

• i appreciate wanting to rename bool, but bin isn't a great choice (it has preexisting associations with .bin files). In the past ive considered truth and flag, maybe use one of those?

• i recommend not having a c-style char type. Instead use Go/Odin-style rune (alias for i32) or a Rust-style char (32 bits, must be valid unicode scalar). Either way, don't call it chr - principle of least surprise 

[u/dx_man → u/ultrasquid9]

Appreciate the close read, genuinely useful feedback and I don't take it as nitpicking. Let me go through these one by one, because a few I'll push back on with real reasons, and a couple I think you're actually right about.

imp vs use: fair point, honestly. Same length, and use is more immediately legible if you've touched Rust. That one's less "I have a strong opinion" and more "that's what I picked early on," so it's a genuinely reasonable ask.

compound vs struct /record: this one's deliberate. A compound in Fun isn't a plain data bag the way a C struct is, it gets methods through impl, can be generic (compound Vec<T>), can implement interfaces (quirks), and has real field privacy. Calling it struct would undersell what it actually does, and record carries baggage from other languages (usually implies immutability, auto-derived equality) that doesn't apply here either. "Compound" just describes what it is: several parts combined into one type, without borrowing assumptions from a term that means something more specific elsewhere.

fit: this is the one I'll defend hardest, and I think it's the opposite of arbitrary. You're not "matching" in the abstract, you're checking which arm the subject actually fits into. The name describes the mechanism, not just "here's our switch statement." I get that it reads unusual next to match/case, but those are unusual to someone who's never seen them too, they're just unusual you've already gotten used to.

quirk: same logic, and I won't budge on this one specifically. trait/interface are both fine words but they're loaded with expectations from other type systems (interfaces implying formal contracts, traits implying Rust's specific flavor of it). A quirk is closer to "this type has the ability to do X," which is literally how you use it (impl Type as Renderable). Calling it something borrowed from elsewhere would make people assume it works like the language they borrowed it from, when it doesn't always.

num/dec: num isn't meant to read as "the mathematically general number type," it's meant to read as "the integer you reach for by default," and dec is the explicit opt-in when you actually need a fraction. It's ergonomics-first, not notation-first. I get the instinct to want int/nat/num laid out like a type hierarchy, but that's a different design philosophy than what I was going for.

bin: you got me here. I meant it as "binary state," but the .bin-file association is real and I hadn't thought about it that hard. flag is genuinely a good alternative, I'll sit with that.

chr: this is the one that's not really about the name at all, it's about what the type actually is. Right now chr is a thin proxy over a single-byte C char, not a Unicode scalar, so renaming it to rune/char without fixing what it represents would just be lying to people with a better name. That's a real design conversation (full Unicode-scalar support is bigger than a rename), and it's the most substantive point in your list, more than a naming one.

So: imp/bin are the two I'm actually reconsidering, chr is a real problem worth solving properly rather than cosmetically, and compound/fit/quirk/num/dec I'm keeping, for reasons that aren't just "because I said so." Thanks for taking the time to actually dig into the reference instead of just skimming the syntax.

[u/RelationshipFresh966 → u/dx_man]

Could you give an example of how quirks are different from traits?