Seriously, I think this question is worth asking. Why was Zig chosen as the language when it’s not even stable, and what implications does this have for the long term viability of the project (besides the fact that its _fast_)? Zig’s head guy isn’t even sure when Zig will hit v.1.0, and Bun’s head guy hasn’t really responded either AFAIK.
If Zig dies tomorrow, bun could probably continue using it as-is, perhaps after fixing the bugs they encounter. It's "the API and language spec isn't complete yet" unstable, not "we haven't implemented floating point operations yet" unstable. So far, only the allocalypse has caused major grief in terms of language changes, as far as I know.
Why is it not ready for production if the binaries work just fine?
In one such change, all *Allocator parameters were turned into Allocator parameters (not the missing *). That meant rewriting tons of function bodies and signatures, because passing specific allocators around is one of Zig's strengths. The compiled binaries came out just fine, but every major Zig component needed refactoring from one compiler version to the next.
Demonstrably by this 1.0 bun release it seems safe to say it ended up being a fine decision, no?
That’s just a decision they’ve made themselves. I honestly think it’s an interesting question: can software built on a <1.0 base legitimately call itself 1.0? What if there are big underlying issues discovered within Zig?