Bun Rewrote in Rust. Zig Did Not Lose.
Published: August 31, 2026 · Read Time: 8 min read · Category: Systems
Author: Abhishek Shivakumar (Systems & Audio Engineering)
Bun's rewrite was an engineering decision inside one unusual runtime, not a verdict on Zig. The rivalry obscures the more useful lessons about ownership, testing, AI and project values.
The Headline Is True and Still Misleading
Bun 1.4 ships with its core rewritten from Zig to Rust. According to Bun, the port replaced roughly 535,000 lines of Zig, produced about one million lines of added Rust, and was orchestrated over eleven days with a prerelease Anthropic model. Bun reports that its benchmarks matched or beat 1.3, the Linux and Windows binaries became smaller, and more of Node's own tests now pass.
Those are substantial results. They do not establish that Rust is simply faster than Zig, that Zig caused every defect in Bun, or that a rewrite is now the default cure for technical debt. They establish something narrower and more interesting: one team used an unusually strong test oracle, enormous parallel compute and close human orchestration to change the ownership model of an unusually complicated runtime.
The distinction matters. Programming language arguments compress a system into a logo. Bun is not a small command-line utility. It sits between JavaScriptCore's garbage collector, manually managed native memory, asynchronous I/O, re-entrant JavaScript callbacks and a large C and C++ dependency surface. The correct question is not which mascot won. It is which failure modes Bun needed its tools to make harder.
What Bun Actually Bought with Rust
Bun's own account is specific about the recurring failures: missed cleanup on error paths, use-after-free, double-free, references invalidated by re-entrant callbacks and values that needed to remain visible to JavaScriptCore's collector. Zig provides explicit allocation, defer and errdefer. That model is excellent when lifetime boundaries are legible and the team applies a consistent ownership discipline. Bun's boundaries frequently were not legible.
Rust gives the project destructors through Drop, move semantics, a borrow checker and a mature vocabulary of owned and shared containers. That shifts some lifetime mistakes from runtime observation into compiler feedback. It is a sensible trade for Bun even if it adds complexity elsewhere.
There is an important qualification. Bun deliberately began with a mechanical translation and said it would reduce unsafe code and make the result more idiomatic after shipping. Rust's guarantees apply most strongly to safe Rust; they do not retroactively prove every translated foreign-function boundary correct. The rewrite changes the direction of travel and the set of available enforcement mechanisms. It does not abolish review, fuzzing, sanitizers or systems expertise.
The useful claimRust is a better fit for the ownership failures Bun repeatedly encountered. That is a claim about Bun's architecture and working practices. It is not a universal ordering of systems languages.
Zig Made Bun Possible
The rewrite story begins with a fact that the rivalry often deletes: Jarred Sumner says Zig made the first version of Bun possible. He began with a line-for-line port of esbuild's transpiler, then built a package manager, test runner, bundler, module resolver, HTTP stack and Node compatibility layer at extraordinary speed. Zig's direct control, C interoperability, comptime facilities and pragmatic cross-compilation were part of that velocity.
That is representative of Zig's broader ecosystem. Projects such as TigerBeetle, Ghostty, Mach, MicroZig, libxev and the Zig compiler itself do not share one workload or one ownership strategy. They share a preference for explicit control, simple language semantics, strong C interoperation and build tooling that treats the target platform as data rather than an afterthought.
Zig is also still a pre-1.0 language willing to change its standard library and compiler architecture in pursuit of a coherent long-term design. That creates migration cost today. It also means the project has not frozen premature answers merely to protect a growth narrative. The ecosystem's real test is not whether it retains every famous adopter. It is whether its tools and institutions keep improving for the projects whose constraints match its philosophy.
Andrew Kelley's Post Was About a Relationship
Andrew Kelley's response made the underlying dispute explicit. His central technical argument was that language features cannot substitute for sustained engineering attention: TigerBeetle gets reliability from discipline, testing and a deliberately constrained style as well as from Zig. He also challenged whether Bun's binary-size and performance improvements came from Rust itself or from optimisation work that could have been applied to the Zig codebase.
But the post was not merely technical. It described a failed relationship between the Zig Software Foundation and Bun, opposing views of maintainership, frustration over Bun's code quality, disagreement about AI-generated contributions and resentment around Bun's venture-backed trajectory. Kelley later revised the conclusion, acknowledging that unprocessed resentment made his framing read as a personal attack and apologising to Zig users who worried that they might be treated similarly if they left.
That revision is important. It does not erase the technical criticism, and it does not validate every allegation. It tells us how to read the exchange: as two overlapping accounts from parties with history, incentives and hurt. It is not a neutral language benchmark.
Why the Internet Needs Them to Be Enemies
The two stories are structurally irresistible to online discourse. Rust and Zig are neighbouring answers to systems programming. Bun was Zig's most visible consumer product. Anthropic acquired Bun, then an Anthropic model helped rewrite it. A founder had dramatic performance and productivity numbers; a language creator had a sharp public rebuttal. Every ingredient rewards a winner-and-loser frame.
That frame also converts institutional questions into personal fandom. A company optimising for a widely deployed runtime has different time horizons from a nonprofit stewarding a language. A runtime team wants fewer production crashes next quarter. A language foundation wants semantics and community norms that remain coherent for decades. Neither horizon is imaginary, but they can produce incompatible decisions.
Social platforms remove those constraints and offer a simpler contest: Rust versus Zig, AI acceleration versus craft, founder versus maintainer. People are then asked to defend an identity rather than examine a build graph, an unsafe boundary or a bug distribution. The conflict becomes content, and the software becomes evidence selected after the allegiance.
The Rewrite Was a Process Innovation
The most consequential part of Bun's rewrite may not be Rust at all. Sumner did not issue one vague prompt. The team produced a porting guide, classified lifetimes, trialled three files, split work across isolated worktrees, treated compiler errors as a queue, ran implementer and adversarial-review loops in separate contexts, and used the existing TypeScript suite as a language-independent oracle.
The scale was extreme: Bun reports around fifty continuously running workflows, 6,502 commits and up to sixty-four agents working on compiler errors. The first mechanically translated files did not work. Agents interfered with one another, created stubs and invented dubious workarounds. The human contribution was designing feedback loops that made those failures visible and changing the process when they appeared.
This is not evidence that source language no longer matters. It is evidence that a codebase with separable work, machine-checkable behaviour and a strong test boundary can be transformed in ways that were previously uneconomic. Most projects do not have Bun's test suite, budget, infrastructure or a runtime-independent specification. Copying the headline without those preconditions would bring the risk rather than the result.
| What changed | What it does not prove |
|---|---|
| Bun adopted Rust ownership tools | Zig is generally unsafe or unsuitable |
| Bun 1.4 improved several measured outcomes | Rust alone caused every improvement |
| Agents compressed the porting schedule | Human review and architecture are obsolete |
| The existing suite enabled behavioural comparison | Passing tests prove the port has no latent defects |
What Each Community Can Take from It
Rust has earned its place when a project wants ownership invariants encoded in the type system and can afford the associated complexity. Zig remains compelling when explicit allocation, predictable control flow, C integration, compile-time construction and cross-target tooling are central. Neither proposition requires the other language to fail.
For Zig, Bun is useful pressure. Large applications need stable tooling, observable compile-time costs, clear patterns for ownership and credible answers to memory-safety criticism. For Bun, the rewrite creates a new obligation: demonstrate over time that the safe surface expands, regressions remain controlled and the maintenance burden actually falls. Launch benchmarks are a beginning. They are not a longitudinal result.
For everyone else, the lesson is to measure the defect classes in the system you have. Choose a language, style and verification stack that attacks those classes. If the organisation does not allocate time to correctness, a different compiler can move the boundary of failure, but it cannot supply care.
There Was No Language Election
Bun leaving Zig is significant because Bun is significant. It is not a referendum. Languages are instruments for encoding decisions, and different projects want different decisions made explicit. Rust helped Bun move ownership decisions into compiler-enforced structures. Zig helped a single developer turn an implausibly broad idea into a runtime used by millions.
Both facts can remain true. The interesting future is not one ecosystem absorbing the other. It is projects becoming more honest about where correctness comes from: language semantics, architecture, tests, review, operational feedback and the social conditions under which people do the work.
Primary accounts: bun.com/blog/bun-in-rust, bun.com/blog/bun-v1.4, and andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html. Product figures in this article are Bun's published measurements and should be read as first-party results.