Bun Rewrites in Rust, and Zig's Creator Responds

Jared Sumner's Bun 1.4 blog post is one of those pieces that will get cited in engineering discussions for years — not primarily for the technical decisions, but for how transparently it documents a category of reasoning that the industry usually keeps internal. The rewrite is already in production. Prisma's compute beta shipped on it. Cloudflare moved the Rust build into production. The thing works. But work is the least interesting part of the story.

What Sumner Actually Said

The case for the rewrite rests on something simpler and more honest than most language migration posts ever admit: Sumner was tired. "Our buglist felt bad and I was tired of going to sleep worrying about crashes in Bun," he writes. That's not a technical argument. It's a maintainer's confession, and it reframes everything that follows.

The technical argument is real, though. A long list of bugs from Bun version 1.3 — use-after-free, double-free, memory leaks in error paths — made the core problem concrete. These weren't obscure edge cases. They were the kind of bugs that show up in release notes and accumulate into a reputation. Sumner's reasoning: in safe Rust, most of that list becomes compiler errors before code ships. "Compiler errors are a better feedback loop than a style guide" is the most precise line in the post, and it's hard to argue with.

The mechanics of the rewrite are worth dwelling on, because they're genuinely novel. Sumner spent hours with Claude producing a porting.md document — a structured guide mapping Zig patterns to Rust equivalents — before touching a single source file. Then he started with three files, not 1,500. The approach was deliberately non-idiomatic: translate the logic faithfully first, introduce Rust idioms later. Adversarial review — one agent writes, two agents critique — was baked into the process from the start. Errors were collected into a queue and addressed systematically. The TypeScript test suite, language-agnostic by design, served as the stability anchor throughout.

The result: roughly 972 test files needed to pass, and they did, on all platforms, within roughly eleven days of work. Bun 1.4 fixed 128 bugs that reproduced in 1.3. Memory usage on a specific build-on-every-request workload dropped from seven gigabytes to around 600 megabytes. About 4% of the Rust code sits in unsafe blocks — a number Sumner expects to fall as the codebase gets idiomatically refactored. Nineteen known regressions were introduced and subsequently fixed. Post-merge security review and fuzzing identified further issues addressed through additional PRs.

None of this is a utopian outcome. It's a credible one.

What Kelley Actually Said

Andrew Kelley's response post is harder to read, not because the argument is wrong in every particular, but because the framing undercuts the legitimate parts.

The opening characterization of Sumner as someone with "beginner energy" who was "jumping headfirst into problems that he was not yet equipped to solve" and "leading to mediocre outcomes in terms of engineering" sets a tone that the post never fully recovers from. Kelley walks some of it back — he credits the attitude as healthy for learning — but the scaffolding is already up. By the time he gets to calling out Sumner's code quality directly and suggesting his success owed something to JavaScript's market size rather than his own ability, the reader is primed to receive everything else as grievance processing.

Which is unfortunate, because there are legitimate technical counterpoints buried in there. Kelley argues that some performance gains attributed to the Rust version were achievable in Zig with different configuration choices. He argues the binary size improvements reflect comptime overuse that the Zig team had been flagging for a while. He points out, correctly, that Zig's compilation speed is a genuine advantage the Bun post doesn't address. These are real observations. They deserve engagement on their merits, and they get less of it because of what surrounds them.

The most revealing line in Kelley's post, though, isn't the technical critique. It's this: "When Jared announced the Rust rewrite, we were ecstatic... and now I'm metaphorically sipping delicious tea from a mug that says it tastes like it's not my problem anymore."

That's a remarkable sentence for the president of a software foundation to publish about a project that was, until recently, the most visible application of his language in the wild.

The Governance Story Nobody's Naming

Start from that tea mug quote and follow where it actually leads, because it points somewhere more important than the language debate.

By Kelley's own account, the Zig Software Foundation came to view Bun as a liability. Bun's memory management problems were surfacing in public bug trackers, in press coverage, in user complaints — and Bun was widely understood as the flagship Zig project. The Foundation had no real mechanism to address this. They attempted, Kelley writes, to guide the Bun team toward better practices. Those attempts were described as "futile." There was no formal relationship governing what "guidance" meant, who was obligated to receive it, or what either party could do if it didn't work. When the relationship deteriorated, both parties just... waited for it to be over.

This is not a Zig-specific problem. It's a governance vacuum that open source foundations have been stumbling into for decades, and almost none of them have built a real policy response to it.

The Apache Software Foundation's model is instructive. Apache maintains explicit project lifecycle governance — projects can be moved to the "Attic" (effectively retired) with a formal process, and the ASF brand is tightly controlled in ways that create clear separation between "Apache project" and "software that uses Apache stuff." That distinction matters when a project's code quality starts reflecting on the brand. The Python Software Foundation takes a different approach: PyPI packages aren't "PSF-endorsed" in any formal sense, which means the Foundation gets some insulation from ecosystem quality problems, but also means it has almost no leverage when a high-profile package becomes a liability. The Rust Foundation, for its part, has been cautious about getting into the business of ecosystem endorsement at all, partly because the Rust community learned from watching other foundations that prestige association cuts both ways.

The Zig Software Foundation had none of these mechanisms. Bun was the ecosystem's most prominent proof point — the project that made people know Zig was real and production-capable. It was also, apparently, the project making the Foundation's leadership lose sleep. That's the trap. The same project that makes your language visible is the one you can least afford to publicly distance yourself from, because distancing it means admitting the association was a problem, which raises questions about why you let it represent you in the first place.

A tiered endorsement framework — something like "built with Zig" versus "Zig Foundation partner project" with explicit quality criteria for the latter — would have given the Foundation a vocabulary for exactly this situation. It could have said, publicly and without drama, "Bun is a significant Zig application; it is not a Foundation-endorsed project; here is what Foundation endorsement requires." That's not disavowal. It's just governance. The Python ecosystem has informal versions of this (the distinction between "popular" and "recommended" is real, even when unstated), but informal versions break down precisely when the relationship gets difficult.

The Foundation would have had to build that framework while Bun was still their best advertisement for Zig's viability. That's when you'd have had to say: this project brings us visibility and donations — Sumner donated significantly to the Foundation, unprompted — and we are going to create a formal tier that this project doesn't yet qualify for. Almost no foundation does that. The fundraising math doesn't support it. So the governance vacuum persists, quietly, until one party writes a blog post that goes viral.

Kelley's post is that blog post. Sumner's didn't need to be, because he handled the exit cleanly — acknowledged what Zig gave him, explained what Rust solved, moved on. The Foundation is left holding the tea mug, publicly, with nowhere institutional to put it down.

---

Dev Kapoor covers open source and developer communities for Buzzrag.