Jarred Sumner rewrote 960,000 lines of Bun from Zig to Rust in six days. He might throw it all away.

Jarred Sumner posted a number on May 9 that made the dev world do a double take. 99.8% of Bun’s test suite passes on a version of the JavaScript runtime rewritten from Zig to Rust, a 960,000-line port done in six days with Claude.

Then he said something equally notable: “We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.”

That combination, a working 960K-line rewrite that might land in the trash, tells you more about the state of AI-assisted development than any benchmark could. But it also tells a quieter story about why Bun’s relationship with Zig has been deteriorating for months.

How a six-day rewrite works

Sumner used Claude to assist with the port, though he was careful to qualify the process. “It wasn’t ‘Claude, rewrite Bun in Rust, make no mistakes,’” he clarified. The rewrite followed a two-phase approach documented in a Zig-to-Rust porting guide the team published alongside the experiment.

Phase A captures the logic of each Zig module in Rust without worrying about compilation. Phase B makes it compile crate by crate. The 99.8% test compatibility figure covers Linux x64 with glibc; other platforms were still in progress as of the announcement.

The scale is worth pausing on. 960,000 lines isn’t a small utility. Bun is a JavaScript runtime that bundles a transpiler, a package manager, a test runner, and an HTTP server. Porting all of that, even with AI assistance, in under a week, suggests that the Zig-to-Rust translation surface is more mechanical than creative. The languages share enough low-level DNA (manual memory control, no garbage collector, C interop) that much of the conversion follows patterns.

Sumner noted one practical benefit already: the Rust port compiles faster than Bun’s Zig fork using upstream compilers.

Why Zig and Bun fell out of alignment

The rewrite didn’t come from nowhere. Bun’s team created a Zig fork that achieved 4x faster debug compilation times through parallel code generation with LLVM. That’s a massive improvement for a project of Bun’s size. But Zig’s maintainers rejected the changes, citing concerns about non-deterministic behavior in parallel compilation.

There’s a deeper tension. Zig has a strict no-AI policy for contributions to the language. That puts Bun in an awkward position: Anthropic acquired Bun in late 2025 and integrates it into Claude Code. Running your JavaScript runtime on a language that won’t accept AI-generated patches while your parent company’s entire business is AI creates friction that’s hard to paper over.

The Register put it bluntly: Zig’s no-AI stance is “embarrassing for Anthropic.” Whether or not that’s the primary driver of the Rust experiment, it’s clearly a factor. Sumner himself has said he expects AI to dominate open-source development going forward.

What Rust gives Bun (if they ship it)

Sumner’s motivation wasn’t abstract language preference. It was stability. “I am so tired of worrying about and spending lots of time fixing memory leaks and crashes and stability issues,” he wrote. Rust’s borrow checker and ownership system enforce memory safety at compile time, making entire categories of bugs structurally impossible.

Zig takes a different approach. It gives you manual control and trusts you to get it right. That works for small codebases and experienced teams, but at 960,000 lines, “trust the developer” produces a long tail of subtle memory bugs that eat engineering time.

The Rust compiler also makes unsafe code explicitly visible. Any block marked unsafe becomes a target for review and eventual refactoring. In Zig, the boundary between safe and unsafe operations isn’t surfaced by the language itself.

Bun’s users have noticed the stability issue. Community reactions to the announcement were generally positive, with multiple users on Hacker News noting that while Bun is fast, significant bugs and memory leaks have been persistent complaints. One commenter put it directly: “it always seemed a bit crazy to base your product off a language that is still in beta.” Zig’s pre-1.0 status means breaking changes can land at any time, and Bun’s fork exists precisely because the team needed stability the upstream wouldn’t guarantee.

The AI rewrite precedent

Bun isn’t the first project to attempt a major AI-assisted rewrite. Cloudflare reimplemented Next.js API components in one week using AI. Ladybird ported its JavaScript engine from C++ to Rust in two weeks. But 960,000 lines in six days with 99.8% test compatibility is a new scale for the pattern.

The question isn’t whether AI can do this. Clearly it can. The question is whether the output is maintainable by humans afterward. A codebase that passes tests isn’t necessarily a codebase that’s well-structured, idiomatic, or debuggable by the team that’ll maintain it for the next five years. Sumner promised a blog post covering benchmarks, memory usage, and maintainability, but hasn’t published it yet.

There’s a related concern that the Hacker News thread surfaced: AI-generated Rust often leans heavily on unsafe blocks to make the type system cooperate. If the Rust port achieves 99.8% compatibility by wrapping most of the tricky parts in unsafe, you’ve traded Zig’s implicit unsafety for Rust’s explicit unsafety without gaining much actual safety. The upcoming blog post needs to address the unsafe ratio to answer whether this port is genuinely safer or just differently annotated.

The compilation speed angle is interesting too. Sumner noted the Rust port compiles faster than Bun’s Zig fork using upstream compilers. That’s partly because Bun’s Zig fork uses LLVM parallel codegen (the improvement Zig’s maintainers rejected), while the Rust version uses Rust’s own mature parallel compilation pipeline. For a project this size, compile times matter for developer velocity almost as much as runtime performance.

What does this mean for Zig?

Zig is still a pre-1.0 language. That’s been both its appeal (fast iteration, fresh design choices) and its liability (breaking changes, limited tooling). Bun was Zig’s highest-profile production user and its best advertisement that the language can handle serious system-level work.

If the Rust port ships, Zig loses that proof point. The optics are particularly rough because the friction points that pushed Sumner toward Rust (rejected upstream patches, no-AI policy) are policy choices, not technical limitations. Zig’s maintainers prioritized determinism and human authorship over accommodating their largest downstream user. That’s a defensible position, but it may come at the cost of their most visible success story.

Andrew Kelley, Zig’s creator, hasn’t publicly commented on the experiment. The Zig community’s reaction has been mixed: some see it as vindication that Zig needs to stabilize faster, others argue that Bun’s departure (if it happens) reflects Anthropic’s priorities more than Zig’s shortcomings.

What this means for you

If you’re building on Bun, nothing changes today. The Zig version is what ships. Sumner has been explicit that this is an experiment, not a migration.

But the experiment matters beyond Bun. It’s a proof of concept for something a lot of teams are wondering about: can you use AI to escape a language bet that isn’t working out? The answer appears to be “yes, at least mechanically.” Whether the resulting code is production-quality is the harder question, and the one Sumner’s upcoming blog post needs to answer.

Watch for that post. It’s where this story goes from interesting experiment to actual decision.