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