NEWS

Bun rewrites 535,000 lines of Zig to Rust in four months with AI

The creator of the JavaScript runtime used AI agents to port the entire codebase, eliminated chronic memory leaks, and reopened the debate over trusting millions of machine-generated lines in production.

Bun rewrites 535,000 lines of Zig to Rust in four months with AI
Image: Redação iMasters

O Bun, runtime JavaScript/TypeScript que também funciona como bundler e gerenciador de pacotes, trocou sua linguagem de implementação de Zig para Rust.

Bun, a JavaScript/TypeScript runtime that also works as a bundler and package manager, switched its implementation language from Zig to Rust. Jarred Sumner, the project's creator, announced that the complete rewrite of 535,496 lines of code was finished in four months, a task he himself estimated would take a year with a dedicated human team. The result was released in Bun v1.4.0, in August 2026, according to InfoQ.

The motivation isn't aesthetic. According to Sumner, a large share of Bun's historical bugs were use-after-free, double-free, and "forgot to free memory" issues in error paths, exactly the class of failure that Rust's borrow checker turns into a compile-time error instead of a production bug. In his view, "compiler errors are a better feedback loop than a style guide."

How the rewrite was done

Instead of porting the code by hand, Sumner tested whether a pre-release version of an Anthropic model (which InfoQ cites as "Claude Fable 5") could rewrite the whole of Bun in Rust. The experiment was only viable because Bun's test suite is written in TypeScript and doesn't depend on the runtime's language: more than a million assertions served as an objective criterion for validating each transpiled section.

The process was orchestrated across roughly 50 dynamic workflows, with separate roles for agents: an implementer translated Zig into Rust, supported by two living documents, PORTING.md (a mapping of Zig patterns to Rust) and a LIFETIMES.tsv (the lifetime of each struct field in the codebase). Two adversarial reviewer agents, running in isolated context windows with access only to the diff, had the sole task of finding bugs and behavioral divergences. A fixer agent handled the issues flagged. Sumner sums up the division bluntly: "the implementer doesn't review, the reviewer doesn't implement."

The scale of the process is the most striking figure: the work was split across four workspace shards, each running 16 agents, totaling 64 Claude instances running in parallel. At peak, the system generated roughly 1,300 lines of code per minute and hit 695 commits per hour. Getting the full test suite to pass cost $165,000 in API tokens, the equivalent of 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. For comparison, Sumner estimates that the same work, done manually, would take three engineers with full context of the codebase about a year.

What bugs remained, and what new ones appeared

The mechanical rewrite didn't come for free. InfoQ reports 19 subtle semantic regressions caused by syntactic similarities between Zig and Rust (code that looks the same in both languages but behaves differently). Eleven rounds of security review with Claude Code Security fixed additional issues, and a coverage-guided fuzzing regimen, running 24 hours a day against all of Bun's parsers, resulted in 15 fix pull requests.

In the end, Bun v1.4.0 resolved 128 bugs that had existed since v1.3.14, including the memory leaks that motivated the entire project. The test cited by InfoQ is concrete: in a continuous bundling scenario, running 2,000 consecutive calls to Bun.build(), the Zig version had memory consumption climb past 6.7 GB, while the Rust version stabilized at 609 MB. HTTP throughput also rose, between 2% and 5%.

The reaction from Zig's creator

The rewrite didn't go unchallenged, and the most direct criticism came from within the Zig community itself. Andrew Kelley, the language's creator, published a piece titled "My Thoughts on the Bun Rust Rewrite" questioning the narrative. According to him, there's a false dichotomy between "choosing a language feature or a style guide" to avoid bugs, when in practice bugs get eliminated by dedicating engineering effort to it, not by switching languages. Kelley goes straight to the heart of the controversy: if the test suite is enough to validate a million lines of code that no human has reviewed, why wasn't it enough to catch the bugs that existed in Zig?

InfoQ also records a comment from a user identified as vitaminCPP, who frames the case in more neutral terms: Bun becomes an important canary for the industry on whether massive, LLM-generated codebases can remain sustainable across the software's lifecycle, not just on merge day.

What this changes for those choosing a stack here

For those deciding on a runtime and language for a real project, the Bun case serves as concrete data, not a recommendation. First, it confirms that memory safety remains the strongest argument in favor of Rust over languages without a garbage collector and without a borrow checker: Bun's own team preferred to pay the cost of an entire rewrite rather than keep chasing use-after-free bugs in production. Second, it shows the real cost of a migration of this scale even with AI: $165,000 in tokens and four months of operation with 64 agents running in parallel isn't something that fits most teams' budgets, and the cost comparison with

Translated from the Brazilian Portuguese original · Read the original