GoKawiilOn May 14, PR #30412 merged into Bun's main branch: a little over a million lines of Rust, 6,755 commits, generated almost entirely by Claude Code agents over nine days. Anthropic, which acquired Bun in December, supplied the agents. The Zig implementation that powered Bun is gone. Jarred Sumner's own words - "we haven't been typing code ourselves for many months now" - are the part everyone quoted, and the part that turned a routine merge into a 685-point Hacker News thread with the PR itself split almost evenly between thumbs-up and thumbs-down.
The Rust rewrite passed 99.8% of the existing test suite. That number is enormous and significant, but let's be precise about what it actually says: it says that the new implementation behaves like the old one at the runtime's public interface. That's it. It does not say that the new implementation is safe, or better, or even good. Those are different claims.
The benchmarks are neutral-to-faster, and the binary shrank by a few megabytes (from a starting point around 93MB on Linux on x64, for example). If that were the whole story there would be nothing to add: it'd be a "good merge," I suppose, because "smaller" and "faster" while not losing test validation are "good attributes." But the actual stated reason is not one of those reasons and that suggests that there's more here than people are thinking about, blinded by fascination with Rust - a fascination I share - and with the interest in whether an LLM can accomplish something like this at all.
The stated reason was safety
Sumner has been consistent that the motivation was not performance. The Zig codebase had cost the team years of debugging memory bugs - use-after-free, double-free, the usual parade of potential errors - and the pitch for Rust was compiler-assisted memory safety. Catch the class of bug at compile time that Zig, like C and C++, leaves to the programmer. That is a coherent and respectable reason to move. In fact, it seems to be the common reason most large systems projects cite when they reach for Rust.
But: the rewrite ships with somewhere more than ten thousand unsafe blocks across more than 700 files. For scale: uv , a Rust project of broadly comparable size from the same general corner of the ecosystem, contains 73. That is not a rounding difference. That's two orders of magnitude, and it is the direct consequence of the porting strategy.
The team published a porting guide instructing the agents to translate the Zig faithfully - same architecture, same data structures, file by file. A faithful port of manual memory management does not become memory-safe in transit. It becomes manual memory management wearing a mask made of Rust. Every place the Zig code did something the borrow checker would reject, the translation reached for unsafe , and the borrow checker stands down exactly where it was supposed to do the most good.
Todd Smith commented to me that they didn't even have to fail this way; they could have used guardrails to say "you cannot use unsafe " and added a git pre-commit hook to forbid it for real. Given such restrictions, a good LLM would work with them, adding memory safety as it went, but even this requires review: this is, as Todd said, a good reason on its face not to attempt such ports.
So the 99.8% test pass rate and the 10,000+ unsafe references are not in tension at all. They are the same fact viewed twice. The test suite passes because the port is faithful. The unsafe count is high because the port is faithful. Faithfulness was the goal, and faithfulness was achieved. What was not achieved - what cannot be achieved by faithful translation - is the safety property that the whole exercise was supposed to use as justification.
You can have a faithful port or you can have idiomatic safe Rust. The first is what an LLM translating file-by-file produces. The second is what the memory-safety argument promised. They are not the same artifact, and the test suite cannot tell them apart, because behavioral equivalence at the public interface is blind to whether the bytes underneath are sound.
... continue reading