That's like saying data centers shouldn't use slightly faster CPUs because they aren't tested yet.
You burn those CPUs in. You run them a bunch. Measure them. Measure their efficiency gains. If the gains are real, make a plan for scaling them up. Have fallback plans. The usual stuff. If a company has someone that does this as their job, they're on it.
If Bun affected your source code or development process, I would understand this perspective. Maybe don't use Bun-specific APIs yet, and just stick with the Node compatibility.
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.
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.
With a codebase this size theres a real chance of having miscompilations in there.
What's the points of running a safe language on broken infrastructure, it's garbage in garbage out.
And with Zigs recent plans to replace llvm with their own backend I'm not even sure if they won't continue scope creeping into vapourware.