Comment by bendmorris
2 hours ago
As a comparison point, someone decided to try to fix the issues in the Zig original and is now claiming sub-second build times, plus fixed bugs, by modernizing the codebase and sticking with best practices - indicating that all of the issues that justified the rewrite were self-inflicted and addressable.
https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
I have no skin in this game, and the Zig version is also using LLMs if that helps take the culture war out of it. But, it has always been true in my experience that someone who really understands a problem space can outcompete someone who just throws resources (in hundreds of thousands of dollars of token spend) at it.
> indicating that all of the issues that justified the rewrite were self-inflicted and addressable
The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.
They also complained about build times, and in fact the Rust rewrite started immediately after some other drama about Bun being unable to contribute back LLM-written changes to the Zig compiler to improve build times, and the Zig team rejecting them in principle. So while memory issues did become the focus later, I don't think it was the entire story.
Migrating to Rust in a one-to-one translation with unsafe blocks does not make the code any more safe initially. It might provide tools to do a significant refactor that solves lifetime issues with Rust's help, but I haven't seen evidence that they've done that either. They're also embedding a large C++ codebase, JavaScriptCore, so there are always going to be unsafe areas and touchpoints where memory issues could live, and Rust won't magically solve them.
It wasn’t just on principle that those changes were rejected, they also stated the bun changes were not actually that great or general enough to upstream.