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

[hiccuphippo]

No, they changed the allocator API so everyone had to update their code, here's the story:

https://pithlessly.github.io/allocgate.html

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

[sroussey]

Because they may yet still change the language spec.

[jeroenhd]

Because an update to the compiler could come out next week that completely alters the language. If you're developing a product in this language, you'll need to put significant effort into keeping it up to date, and any dependencies you've downloaded in source form may not work on the most recent compiler.

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.

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

[pseg134]

Well sure, it can legitimately call itself anything. You are wondering if Bun’s standards for 1.0 match up with the standards for 1.0 that you have in your head, but of course only you can answer that.

[rockorager]

I don't see why not. 1.0 would mean the API isn't changing. And they can certainly swap out the language and still keep the API the same.