Despite the 1.0 release tag, given that it's written in Zig, which is super duper Alpha, I'd trust it only as far as I can throw a floppy with its source code.
I don't have any opinion on Bun itself. But as someone who is pretty experienced in running large scale services, I wouldn't have a problem to use a tool that is marked as stable but internally built on top of unstable tools. As long as compilation is mostly deterministic (which is usually given for compilers), a good set of unit and integration tests should prove that the software is actually doing what its supposed to do and can be trusted with workloads. If those tests are not available, then even using a mature language might not provide a guarantee that the actual product is better.
Sure - the Bun developers might have a super hard time if Zig changes its syntax, library APIs or other things. But that would be a maintenance hassle for the Bun developers, and not necessarily for the Bun users.
A project can only be as reliable as its compiler. Zig currently suffers from a number of miscompilation [0] that is quite higher than for a more mature compiler.
It matters plenty if your production system goes down because of bugs caused by miscompilation of your js runtime. This level of instability doesn't uphold the social contract that a 1.0 implies.
It does worry me as a potential adopter of Bun what the long term outlook of the project is if the language used to write Bun isn't very accessible to prospective open source contributors.
You seem to be implying that zig is not open source or is otherwise unfriendly to contributions...?
It's a 501(c)(3) non profit and has been open source since `git init`. Even the financials are transparent to the public. What else could we possibly do?
Zig being a language that most people are not familiar with is a very high barrier of entry in it of itself.
Given how few projects are written in it, the ROI of learning it is not that great.
I'm not 'against' Zig, it's just basic Lindy effect stuff. People don't want to build or invest in a foundation and then left hung out to dry.
Just like the rest of my development choices, I try to take calculated risk so that the platforms I'm building on have a high chance of lasting into the future.
We all know that a rewrite due to obsolescence can be the death knell for a project.
I’m not saying they’re not friendly, I’m just saying learning a new language for probably the single purpose of contributing to this repo is a pretty high barrier of entry for contributors. It is great you overcame it.
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.
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.
Sure - the Bun developers might have a super hard time if Zig changes its syntax, library APIs or other things. But that would be a maintenance hassle for the Bun developers, and not necessarily for the Bun users.