Bun Rewrites 535K Lines of Zig to Rust in 11 Days Using Claude

Jarred Sumner just published the technical details behind Bun's rewrite from Zig to Rust - 535,496 lines of code translated in 11 days using Claude. The post immediately hit the top of Hacker News with 641 points and 377 comments, sparking debate about AI-assisted code migration, memory safety tradeoffs, and whether this is a win or a warning for Zig.

What Actually Happened

Bun, the JavaScript runtime that powers Claude Code, was originally written in Zig. The choice made sense at the time - Zig offers C-level control without the ceremony. But mixing Zig's manual memory management with JavaScript's garbage collector created a class of bugs that kept appearing: use-after-free, double-free, and memory leaks at error boundaries.

From the blog post:

A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path.

Rather than chase these bugs one by one, the Bun team (now part of Anthropic) decided to port the entire codebase to Rust. The borrow checker would catch these memory issues at compile time instead of runtime.

The Numbers

• 535,496 lines of Zig translated to Rust
• 11 days of continuous Claude Code workflows
• $165,000 in API costs at standard pricing
• 6,502 commits with adversarial review
• 5.9 billion uncached input tokens
• 690 million output tokens

The rewrite used approximately 50 dynamic workflows running continuously. Rather than prompting Claude to "rewrite Bun in Rust" in one shot, the team built systematic translation pipelines with multiple Claude instances reviewing each other's work.

The Results

The mechanical port delivered measurable improvements:

• 20% smaller binary (from linker deduplication flags)
• 5% faster performance (from LTO optimizations)
• Zero outstanding memory leaks in the tracked bug list
• Full test suite passing on all 6 platforms by May 14

Claude Code v2.1.181 and later already ship with the Rust port of Bun.

What HN Is Saying

The Hacker News thread surfaced several recurring debates.

The "Vibe Coding" Question

Multiple commenters questioned whether AI-generated code at this scale can be maintainable:

"535k lines in 11 days? With 8-hour working days that's 100 lines per minute. There's no way you're comprehensively reviewing code that quickly."

Others pushed back, noting that Bun is already shipping in production:

"They rewrote the entire thing with extensive LLM use. It's apparently out there, shipped in the real world, with people saying it's good. I think it's a pretty clear win for them."

Trust in Jarred

Some commenters expressed skepticism about the messaging, pointing to earlier statements where Jarred said there was "a very high chance all this code gets thrown out completely" - just 9 days before merging to main.

From dfabulich's comment:

"When the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of unsafe, no Miri tests at all, and, sure enough, it exposed UB in safe Rust."

What This Means for Zig

The rewrite sparked existential questions about Zig's niche:

"It can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%."

Defenders noted that Bun's codebase had unique challenges - integrating with JavaScriptCore's garbage collector - that don't apply to typical Zig projects. The language is still pre-1.0 and evolving.

The Real Cost

At $165,000 in API costs plus Jarred's 11 days of work, this was not cheap. But as several commenters noted, hiring a team to manually rewrite 535k lines would cost far more. The question is whether the resulting code is genuinely maintainable or if Anthropic is now committed to maintaining it with more AI.

Why This Matters

Three takeaways for developers watching the AI-assisted coding space:

1. LLM translation is production-ready for certain patterns. Mechanical, line-by-line ports between similar languages work. The translation preserved Bun's architecture while gaining Rust's safety guarantees. This is different from asking an AI to architect a system from scratch.

2. Adversarial review matters. The Bun team ran multiple Claude instances reviewing each other's work, catching issues that single-pass generation would miss. This pattern - having AI critique AI - is becoming standard for high-stakes code generation.

3. Test coverage is the real safety net. Bun's million-assertion test suite caught regressions that code review alone would miss. The blog post explicitly calls out: "fixing the process that generates the code instead of hand-fixing the code." When generation is automated, the tests become the source of truth.

The Bigger Picture

Bun powering Claude Code creates an interesting loop: Anthropic's AI coding tool runs on a runtime that was itself rewritten by Anthropic's AI. If bugs surface, they can throw more Claude at the problem.

For teams considering similar migrations, the Bun case study suggests AI-assisted rewrites work best when:

• The source and target languages have similar semantics
• You have comprehensive test coverage
• You build systematic pipelines rather than one-shot prompts
• You budget for significant API costs

The debate over whether this is "real" software engineering or elaborate autocomplete will continue. But Bun is shipping, Claude Code users are running it, and the memory bugs are fixed. For a 535k-line codebase, that's a practical outcome.

Sources

• Bun blog post: Rewriting Bun in Rust
• Hacker News discussion (377 comments)
• Andrew Kelley's response
• Bun GitHub repository

FAQ

How much did the Bun Rust rewrite cost?

Approximately $165,000 in Claude API costs at standard pricing, plus 11 days of Jarred Sumner's time building and running the translation workflows.

Is the Bun Rust port stable?

Claude Code v2.1.181+ ships with the Rust port. The team reports full test suite passing on all 6 platforms (macOS, Linux, Windows - each on x64 and arm64).

Why did Bun switch from Zig to Rust?

Memory safety. Mixing Zig's manual memory management with JavaScriptCore's garbage collector created recurring bugs - use-after-free, double-free, and memory leaks. Rust's borrow checker catches these at compile time.

Can I use this approach to rewrite my codebase?

The pattern works best for mechanical translations between similar languages with comprehensive test coverage. It's not a replacement for architectural decisions or understanding your codebase.