My Thoughts on Bun's Rust Rewrite | Jiacai Liu's personal websiteMy Thoughts on Bun's Rust Rewrite<br>2026-05-16<br>Updated: 2026-05-16<br>tags:<br>zig<br>rust<br>bun<br>Table of Contents

Before we discuss Rewrite Bun in Rust, there's something that needs to be said, because no one is saying it.<br>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.<br>Jarred himself said: the architecture doesn't change, the data structures don't change.<br>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.<br>The Zig community doesn't need Bun's gratitude, but please don't pretend this rewrite happened because Zig itself is inadequate.<br>The Real Issue No One Dares to Say<br>Now, let's discuss the rewrite itself.<br>6,755 commits, branch name claude/phase-a-port, PR opened May 8th, merged May 14th.<br>Six days. A full rewrite of a production-grade JS runtime, merged in six days.<br>Let that number sit in your mind for a second.<br>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.<br>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.<br>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<br>Someone will push back here: the test suite passes on all platforms – isn't that validation?<br>No.<br>A test suite validates the correctness of known behavior on known paths. It does not validate:<br>Whether error paths are handled correctly<br>Behavior at boundary conditions under stress<br>State consistency in concurrent scenarios<br>Whether the memory model conforms to intent under extreme conditions<br>Jarred himself admitted: memory issues when re-entering across JS boundaries – the Rust compiler can't handle that; it still relies on humans.<br>And those parts that rely on humans? No human has reviewed them.<br>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.<br>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<br>There's a political-economy dimension here that technical discussions usually ignore.<br>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.<br>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.<br>Jarred says this version is still in canary, and there's optimization and cleanup work to do before official release.<br>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.<br>This will become very real pain at some future severe bug's debugging scene.

Zig's "Problems" Were Misdiagnosed<br>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.<br>This is true. But the conclusion...