[vntx]

Wow, that many guarantees should persuade me to base my tech stack on Bun and Zig.

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.

[jeroenhd]

Zig is fast, promising, compatible with existing C libraries, and relatively barebones. The language itself may not be ready for production, but the binaries built in the language work just fine.

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.

[nusaru]

What does "allocalypse" mean here? Were memory allocations in Zig less explicit in the past?

[omginternets]

>The language itself may not be ready for production, but the binaries built in the language work just fine.

Why is it not ready for production if the binaries work just fine?

[2c2c2c]

they probably figure the developer velocity gained from using it over c++/rust is worth possibly having to make large refactors if a feature in the language is removed.

[warent]

it's possible that they chose Zig if this started as an unpaid passion project, and it simply sounded the most interesting to them.

Demonstrably by this 1.0 bun release it seems safe to say it ended up being a fine decision, no?

[afavour]

> 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?