Changes to Zig can still be very significant. I found myself stuck between a rock and an hard place when I found out that:
- 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.
True, though you can't claim that's an analogous situation - C++ wasn't in alpha when the JVM was implemented.
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.
Well sure if you start adding more conditionals and change the original question you can call anyone who answered the original question in good faith a liar.
That's not what happened here. If you have difficulty keeping context of the thread we're all in, scroll up and reread. Snarking (and being wrong to boot) contributes nothing to the discussion.
are you saying that zig is currently turing complete and that in the future it might not be? because that's the only thing that could force a change to what is possible in the language.
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.