My Thoughts on Bun's Rust Rewrite
Table of Contents
Before we discuss Rewrite Bun in Rust, there's something that needs to be said, because no one is saying it.
Bun stands where it does today because of Zig.
Jarred chose Zig back then not because it was "cool," but because Zig enabled a small team to rapidly prototype a high-performance JS runtime without a GC, without a heavy runtime. Zig's low friction, direct memory manipulation, and straightforward C interop were the core reasons Bun could punch above its weight on performance with an extremely small team in its early days. The architecture, data structures, and low-level design of Bun that you see today – that was shaped by Zig.
Jarred himself said: the architecture doesn't change, the data structures don't change.
In plain English: the skeleton that the Rust rewrite inherits was built with Zig. Building the foundation with Zig, shipping the product with Zig, raising funding with Zig, and then switching to a more "mainstream" tech stack after the company gets acquired and has grown strong – there's nothing wrong with this. It's a normal business decision. That's how tech debt works in Silicon Valley startups.
The Zig community doesn't need Bun's gratitude, but please don't pretend this rewrite happened because Zig itself is inadequate.
The Real Issue No One Dares to Say
Now, let's discuss the rewrite itself.
6,755 commits, branch name claude/phase-a-port, PR opened May 8th, merged May 14th.
Six days. A full rewrite of a production-grade JS runtime, merged in six days.
Let that number sit in your mind for a second.
There's a fundamental principle in software engineering: code you don't understand should not run in production. Not because it necessarily has bugs, but because when it does bug out, you won't know where to start looking. This principle isn't conservatism – it's the baseline of maintainability.
6,755 commits, not a single line written by a human. The PR's reviewer list: coderabbitai[bot] reviewed it, claude[bot] reviewed it, and the only human reviewer alii's status was "Awaiting requested review" – hadn't even looked.
Code written by Claude, reviewed by Claude. This closed loop isn't logically impossible, but it means: no human being has actually read this codebase in its entirety.
"All Tests Pass" Doesn't Mean What You Think
Someone will push back here: the test suite passes on all platforms – isn't that validation?
No.
A test suite validates the correctness of known behavior on known paths. It does not validate:
- Whether error paths are handled correctly
- Behavior at boundary conditions under stress
- State consistency in concurrent scenarios
- Whether the memory model conforms to intent under extreme conditions
Jarred himself admitted: memory issues when re-entering across JS boundaries – the Rust compiler can't handle that; it still relies on humans.
And those parts that rely on humans? No human has reviewed them.
The more fundamental issue is: AI translates code via local semantic equivalence – it ensures each function behaves identically to the original in isolation, but it doesn't understand the global invariants between functions – those design constraints that aren't written into tests and live only in the original author's head. These constraints might not show up in today's tests, but could manifest six months from now under a specific production load in a completely inexplicable crash.
This isn't a knock on Claude. This is a problem any translation tool – including human programmers – faces without thorough review. At the scale of 6,755 commits, this risk is amplified 6,755 times.
After the Acquisition, the Risk Bearer Has Changed
There's a political-economy dimension here that technical discussions usually ignore.
In the early days, Bun was Jarred betting on himself. Using Zig then, iterating fast, accepting tech debt – that was reasonable startup logic with self-assumed risk.
Now Bun has been acquired by a major company, and its user base consists of real production systems. The risk bearer of this rewrite is no longer Jarred, but every engineer running Bun in production and the users behind them.
Jarred says this version is still in canary, and there's optimization and cleanup work to do before official release.
Canary is a line of defense, but it's not human review. Optimization and cleanup are code quality concerns, not comprehension concerns. A codebase that no one on the team has fully read – no matter how comprehensive the tests, no matter how long canary runs – its internal state is a black box to its maintainers.
This will become very real pain at some future severe bug's debugging scene.
Zig's "Problems" Were Misdiagnosed
Let's return to Jarred's stated reasons for migration: the Zig codebase had too many use-after-free bugs, double-frees, and memory leaks on error paths.
This is true. But the conclusion that "Zig doesn't work" drawn from this diagnosis is wrong.
The correct diagnosis is: in a commercial project that prioritizes rapid iteration, the cognitive tax of manual memory management exceeded the team's budget. This isn't a bug in Zig – it's a structural mismatch between Zig's design goals and Bun's business model.
Zig's target users are: systems programmers who know what they're doing and are willing to pay the price for ultimate control. TigerBeetle used Zig to write a database with virtually no memory bugs, because their team culture and project nature align with Zig's philosophy.
Bun's team culture is fast iteration, fast shipping, fast bug fixes. There's a fundamental tension between this and the rigorous memory discipline that Zig demands. This is a mismatch between Bun and Zig, not a failure of Zig.
Interpreting "our team frequently makes mistakes with this tool" as "this tool is inadequate" is an attribution error. The hammer doesn't fit, but it's not the hammer's fault.
So, Will This Rewrite Work?
Honestly: short-term it'll probably be fine; long-term there are structural risks.
Short-term: tests cover the main paths, the canary phase will expose obvious issues, and Rust's compiler guarantees eliminate an entire class of memory bugs. On the surface, everything looks normal.
Long-term: this codebase has 6,755 commits that no human has fully read. When a bizarre concurrency bug appears six months from now, when some boundary condition triggers anomalous behavior under a specific load, the engineer debugging the problem will face a system that no one has ever truly understood.
A system no one has understood doesn't mean it has no bugs – it means when bugs appear, no one knows why. The difference between these two becomes crystal clear at 3 AM during a production incident.
This is the real technical bet of this rewrite: not Zig vs Rust, but whether AI-generated, unreviewed code can be maintained long-term in production environments.
This question is far more complex than "all tests pass," and far more profound than "Rust memory safety."
The answer – we'll wait and see.
Zig built the foundation, Claude erected the building, human reviewers are still en route.
How long this building remains habitable depends on whether anyone can read the blueprints the first time it springs a leak.