Changes to Zig could force changes to Bun, and changes to Zig are all but guaranteed.
- Zig v0.11 doesn't have async/await, which I needed, because they haven't implemented it yet on the self-hosted compiler;
- I couldn't use v0.10 due to some bugs with comptime in the old compiler, which are solved in v0.11.
Still, while bold, I don't think it's totally unwarranted to tag Bun 1.0. They may have to put some extra effort here and there to work around the language's instability.
This is not a critique of the Zig team, they make it very clear that the language is not ready for production use yet.
Decoupling is of course possible, but the difference here is that the lang powering the runtime is not guaranteed to remain the same language it currently is, since it's in active initial development. That introduces a unique axis of risk to runtime stability, it's dishonest to pretend otherwise.
the internals of bun may need to change when a new version of zig requires it, and the bun developers decide to use that version of zig, but existing versions of zig will continue to exist in the future.
future versions of bun can use existing turing complete versions of Zig if they ever decide to remove turing completeness from the language in the future.
lol