It is extracting a subset of that codebase for deployment purposes. The full version of Bun (presumably in Rust?) will continue to be used for actual development.
So it is not a replacement for Bun, but a supplement to it.
E.g. "it's difficult to make predicitions, especially about the future" ;)
PS: of course for this specific project I don't quite understand the reason. The original Bun was largely a line-by-line port of esbuild from Go to Zig, so it's not like the original codebase was a marvel of engineering to begin with...
But by all means I would love to hear some examples of that.
The author is saying explicitly they don’t want to make a Bun replacement
libghostty is more impactful than Bun IMO. It doesn’t matter to most other developers that Bun was written in Zig, but that such a a good library is written in Zig could have an impact on whether other devs use Zig to write libraries, or if they consider Zig for their app when having libghostty as a dependency
TigerBeetle is also more important than Bun since Zig is a better match for their needs it was for Bun, and TigerBeetle team seems to be a better partner for the Zig foundation. The Bun/Oven team seemed to be an annoyance rather than a synergetic partner.
But in general, pre-1.0, I think any large project that uses it is just a bonus.
Huh? Zig was never dependent on Bun for being relevant. Tigerbeetle, for example, is written in Zig.