Bun’s Rust Rewrite: A Triumph of AI Velocity or a Memory Safety Mirage?
Table of Contents
The Million-Line Merge
In a move that has sent shockwaves through the developer community, Bun has officially transitioned its core implementation from Zig to Rust. The scale of the migration is staggering: over one million lines of Rust code, spanning 6,755 commits, merged into the main branch in just nine days. Most strikingly, the work was not performed by human engineers in the traditional sense, but by Claude Code agents provided by Anthropic, which acquired Bun in December.
Jarred Sumner, the creator of Bun, underscored the shift in the team’s workflow, noting that they “haven’t been typing code themselves for many months now.” While the merge has been framed as a leap forward in productivity, it has ignited a fierce debate on platforms like Hacker News regarding the intersection of AI-generated code and systems programming.
The Performance Paradox
On the surface, the metrics look promising. The Rust rewrite passed 99.8% of Bun’s existing test suite, the binary size shrank by several megabytes on Linux x64, and benchmarks show performance that is either neutral or slightly faster than the previous Zig implementation. To a casual observer, this looks like a textbook success story of AI efficiency.
However, the technical community is focusing on a different metric: the unsafe keyword. In Rust, unsafe blocks are used to bypass the compiler’s strict borrow checker, allowing the developer to perform manual memory management. While necessary for certain low-level operations, an abundance of unsafe code effectively voids the memory-safety guarantees that make Rust attractive in the first place.
Faithfulness vs. Soundness
The Bun rewrite contains over 10,000 unsafe blocks across more than 700 files. To put this in perspective, uv, a Rust project of comparable scale and purpose, contains only 73. This discrepancy is not a coincidence; it is a direct result of the porting strategy.
The AI agents were instructed to translate the Zig codebase faithfully, mirroring its architecture and data structures file-by-file. Because Zig relies on manual memory management, a “faithful” translation to Rust inevitably leads to unsafe blocks whenever the AI encountered logic that the Rust compiler would otherwise reject. Essentially, the project has achieved behavioral equivalence—the code does the same thing—but it has not achieved memory safety. The new codebase is, in effect, manual memory management wearing a Rust mask.
The Auditing Nightmare
The prevailing defense from the Bun team is that this is an early “canary” release and that refactoring to idiomatic, safe Rust will follow. Yet, systems experts warn that “refactoring away” 10,000 unsafe blocks is not a simple cleanup task; it is a monumental auditing challenge.
Verifying that unsafe Rust is sound is a notoriously difficult problem. Even the Rust standard library, authored by some of the world’s leading experts and subjected to intense scrutiny, has produced over twenty CVEs traceable to unsafe code. The sheer volume of AI-generated unsafe blocks in Bun creates a surface area for bugs that may be impossible for a human team to fully audit in a reasonable timeframe.
Industry veterans suggest that a more robust approach would have been to define strict specifications of the product’s observable surface and task the AI with building a new implementation toward those specs, rather than a line-by-line port. By prioritizing speed and faithfulness over soundness, Bun may have traded the long-term stability of a human-curated codebase for the short-term velocity of an AI agent.
