Rewriting Bun in Rust

In his blog post, Jarred Sumner first highly praised the Zig language, stating that without Zig, Bun would not be where it is today. However, as the project evolved, the bug list grew longer—mainly memory management errors (such as use-after-free, double-free, and forgetting to free on error paths). These bugs kept Jarred up at night, worrying about Bun's crash issues. He admitted that the problem is not with Zig, but with Bun's simultaneous use of garbage collection and manual memory management, a hybrid model that no language can perfectly support.

The core reason for choosing Rust is its safe memory management: errors like use-after-free and double-free are caught by the compiler in safe Rust, and the RAII (Resource Acquisition Is Initialization) mechanism provides automatic cleanup through Drop. Additionally, Rust's ownership model can eliminate a large class of memory errors at their source.

The key prerequisite for the rewrite was that Bun's test suite is entirely written in TypeScript and is language-agnostic. This means it can serve as a consistency test suite, automatically verifying whether the new implementation matches the original behavior. Jarred initially treated this as an experiment, using an early version of the Fable model (now part of Mythos/Fable) to attempt automatic migration from Zig to Rust. Unexpectedly, within a few days, a high proportion of tests passed, and the newly generated Rust code closely matched the structure of the original Zig code. His attitude shifted from 'worth a try' to 'I'm going to merge this.'

Over 11 days, Jarred primarily monitored the workflow, manually checked outputs, and prompted Claude in an edit loop to fix issues. The entire rewrite consumed 5.9B uncached input tokens, 690M output tokens, and 72B cached input tokens, costing an estimated $165,000 based on API pricing (thanks to being an Anthropic employee with token waivers). The result was a pull request with over +1 million lines of new code.

Merging such a massive PR required an extremely cautious strategy: using the language-agnostic test suite (millions of assertions) for automatic validation, implementing adversarial code review, and prioritizing fixing the code generation pipeline over manually patching code when issues arise. This approach ensures long-term sustainability.

Economically, the $165,000 API cost seems high, but considering this is a rewrite from scratch of a mature runtime, traditional labor costs could be much higher. In terms of benefits, after integrating the new Rust version into Claude Code v2.1.181, startup speed on Linux improved by 10%, but it's almost imperceptible to users—which was exactly the design goal: 'boring is good.'

Security was the core driving force. Rust's safety guarantees convert many runtime errors into compile-time errors, significantly reducing the risk of crashes in production. However, Jarred also acknowledged that this rewrite relied on the 'current capabilities' of AI, and the token consumption during the pre-merge phase was enormous, so whether it remains feasible in the future requires further observation.

In his classic 2000 article 'Things You Should Never Do, Part I,' Joel Spolsky warned never to rewrite large software. But Jarred's case shows that when AI agents can leverage language-agnostic test suites, dynamic workflows, adversarial review, and pipeline-fixing mechanisms, this old rule may be broken.

Key elements include: a high-quality language-independent test suite, sufficient token budget, systematic review of AI outputs, and the engineering mindset of 'fix the pipeline, not the code.' This provides a reusable methodology for other projects facing similar rewrite dilemmas.

However, the current success remains highly dependent on specific conditions: completeness of the test suite, model capability (here, Fable), and sufficient financial investment. Long-term stability and code maintainability will need to be tested over time.