Bun’s Rust Port and the Dispute with Zig’s Creator

Bun has been ported from Zig to Rust with extensive help from Claude. Jarred Sumner's account explains how the work was organized and credits Zig for making Bun possible. Zig creator Andrew Kelley's response became a separate, highly personal dispute; I know Jarred and disagree strongly with Kelley's characterization.

Bun began as a port of esbuild's JavaScript and TypeScript transpiler from Go to Zig. Sumner chose Zig in 2021 for low-level control and performance, then built an unusually broad toolchain: a runtime, bundler, package manager, test runner and many Node-compatible APIs.

Sumner says Zig enabled him to build that scope quickly and expresses gratitude to its community. At the same time, Bun's scale exposed stability problems, including crashes and memory leaks. The team wanted to prevent recurring classes of bugs rather than only fix individual incidents.

Before the port, the team had already added AddressSanitizer support to its Zig compiler, run sanitizer checks in tests, used safety-checked Windows builds, fuzzed runtime APIs and maintained memory-leak tests. Sumner presents those as serious safeguards that still did not eliminate every problem.

The difficulty is the boundary between JavaScript's garbage-collected objects and manually managed memory. Bun's code has to know which resources are live, how exceptions affect cleanup, and when a pointer can be freed. Zig's explicit control can be valuable, but it places responsibility on the programmer.

Zig uses explicit `defer` and `errdefer` for cleanup; Rust provides ownership checking and `Drop`, while C++ has destructors. These approaches make different trade-offs. Safe Rust can catch certain ownership mistakes at compile time, although unsafe code and foreign-language boundaries still require careful review.

The Bun post considers style guides and review as another route. They can express ownership conventions, but enforcement depends on people and tooling. Sumner also considered C++, already used by some dependencies, yet expected that it would retain similar reliance on conventions for many errors.

His argument for Rust is earlier feedback: safe code rejects many use-after-free and double-free patterns, and `Drop` helps with cleanup. This does not prove a whole mixed-language application is memory-safe, nor does it replace tests, fuzzing or review.

A conventional rewrite of roughly half a million lines of Zig could occupy a small team for a long time while other work continued. Bun's proposed lower-risk path was a mechanical port with minimal behavioral changes, using its existing TypeScript test suite as a language-independent check.

Sumner experimented with Claude and saw enough tests pass to continue. He chose an all-at-once mechanical translation rather than an incremental migration with temporary bridges, planning later refactoring toward more idiomatic Rust. That choice reflects Bun's circumstances, not a universal rewrite recipe.

The central process was a loop: implement a task, review the result independently, apply feedback and repeat. Sumner describes roughly 50 dynamic Claude Code workflows across 11 days for mapping types, porting files, fixing compilation errors, running tests and cleanup.

He monitored the workflows and revised them when they produced problems. The post describes separate implementers and adversarial reviewers, with at least two reviewers examining changes without the implementer's full context. I often use different model families for this kind of second look.

The preparation mattered. Sumner spent hours discussing mappings with Claude and recorded rules in a porting guide: retain the project's architecture, map types and allocators consistently, and avoid inventing incompatible runtime structures. He also reviewed the guide and had agents critique it.

Instead of translating all 1,448 Zig files immediately, he trialed three. An implementer translated each file, reviewers checked equivalence and the guide, and another agent applied fixes. The small trial exposed coordination problems before the work was scaled up.

Concurrent agents interfered with one another, while separate worktrees consumed substantial disk space. The workflow was changed to constrain conflicting Git operations and expensive commands. The broader challenge is how to isolate parallel work without making coordination prohibitively expensive.

The system also hit infrastructure limits: a slow Git operation saturated disk I/O. Rust compilation required splitting the code into roughly 100 crates, which exposed cyclic dependencies. Another pair of workflows classified where dependent code belonged and then performed the refactor.

The compiler became a work queue, but making errors disappear was not enough. Some agents tried to stub functions or justify workarounds with long comments. Sumner adjusted the instructions to seek real fixes rather than merely producing code that compiled.

Once compilation passed, the team still had linking failures and startup panics to resolve before it could run meaningful tests. Some translated code used `unsafe`, so memory leaks remained possible despite the move to Rust.

Large test runs exhausted sockets, spawned thousands of processes and wrote gigabytes to disk. They used operating-system resource controls to constrain runs, though the machine still ran out of space and crashed. Parallel agents need limits on their environment as well as instructions.

The reported failing test-file count fell from 972 to 23 over two days, and Linux later went green. Further workflows handled platform failures and cleanup. Sumner says he merged after the suite passed on all platforms and he manually checked that tests were actually running.

Merging to main was not a versioned production release. I find that distinction useful: a team can integrate a large change for further validation without treating the merge itself as proof that it is ready for every user.

The post reports over 6,500 commits and roughly 1.78 million lines added or rewritten. Before merge, it lists 5.9 billion uncached input tokens, 690 million output tokens and 72 billion cached input reads, estimated at about $165,000 at API prices—not necessarily an actual invoice.

Sumner estimates a manual port would have occupied three engineers for about a year, disrupting other work. I think the relevant alternative may have been not attempting the rewrite at all. That is a counterfactual estimate, not a measured labor comparison.

I expect comparable AI capability to become cheaper over time, but the timing and magnitude are uncertain. The experiment also benefited from access to a prerelease model and Anthropic's resources, so its economics cannot be copied automatically by every team.

The article says the work continued after merge: security reviews and continuous coverage-guided fuzzing were added. It reports roughly 4% of Rust code within `unsafe` blocks, many just one line. That percentage is a useful description of the codebase, not an assurance that the remainder of the system has no safety issues.

Bun reports 19 regressions introduced by the port and 128 fixes for bugs reproducible in the prior version. Those are the project's reported results at the time, not independent proof that every regression or pre-existing bug was found.

One displayed build test shows memory use after 2,000 builds at about 6,745 MB for Bun 1.3.14 versus 609 MB for the newer build. The team also reports smaller binaries and modest speed gains. These are specific measurements, not proof that language choice alone caused each improvement.

I find the write-up valuable because it shows the guide, reviews, tests, infrastructure limits and ongoing work behind the port. The interesting story is not a single prompt magically rewriting a repository; it is the engineering process around repeated generated changes.

Kelley, Zig's creator, published a response describing a breakdown in the relationship between the Zig project and Bun. He acknowledges Bun's financial support and Sumner's gratitude, but criticizes his decisions, management and code quality. I am a friend of Sumner's and read this response with that perspective.

Kelley describes Sumner's early approach as moving quickly into unfamiliar problems and argues that venture funding changed Bun's incentives. I object to the characterization and think Sumner had worked with extraordinary intensity before raising money. Neither account establishes another person's motives as fact.

Kelley suggests crowdfunding could have supported the project. I question whether that is realistic at Bun's scale, pointing to the much smaller donations received by the JavaScript ecosystem effort E18E. Funding situations differ, so this example illustrates the concern rather than proving a universal outcome.

Kelley says Bun donated about $60,000 a year to the Zig Software Foundation before the donation stopped. I highlight that support and argue that commercial funding can pay for both engineering and contributions to an upstream project.

The response also relays harsh accounts of Sumner's management and demanding work expectations. I agree that he has not always been a good manager and say that he was explicit about the intensity of the work. The employee experiences and other workplace allegations discussed here are disputed personal accounts, not independently established findings.

Kelley portrays the relationship as increasingly strained and says the Zig team objected to practices in Bun's code. His examples include assertions and rapid feature development. I see at least some of those as disagreements about engineering practices and reject the personal tone of his response.

Kelley says the foundation viewed Bun as a liability and welcomed the Rust migration. He also raises concerns about low-quality AI-generated contributions reaching the Zig community. Those are his account and assessment; they should not be treated as an independently verified judgment of every Bun contribution.

On the technical side, Kelley argues that the Bun post sets up a misleading choice between style guides and language features, and emphasizes dedicating engineering effort to finding bugs. He also questions relying on a test suite to validate a huge generated port. These are substantive concerns even though I strongly disagree with his framing.

My response is that behavior tests and memory guarantees address different failure modes. A test suite can exercise many cases but cannot establish that every long-running memory issue is absent. Rust's safe subset provides additional compile-time guarantees, while unsafe code, foreign libraries and logic errors still need other checks.

Kelley disputes the performance explanation, asks about fuzzing practices and questions whether binary-size improvements came from the language change. I contest his assumptions about the timing and intent of that work. The video does not independently resolve these technical or historical disagreements.

He also asks for post-rewrite compilation measurements and points to fast Zig compiler builds. I agree that compilation time is a real trade-off: Sumner's account itself describes reorganizing crates to make Rust compilation manageable. One attractive property does not settle the entire language decision.

Kelley concludes that the deeper issue was a relationship breakdown. Based on my conversations with Sumner, I believe he genuinely liked Zig and was disappointed by friction with the foundation. That is my personal account; outsiders cannot infer the full history or motives from it alone.

I object especially to a disclaimer in the version I first read that said there were no personal criticisms, while the article included judgments about Sumner's experience, management and motivations. I asked models to identify examples, but their agreement is not independent adjudication of the dispute.

Kelley later revised the conclusion, saying that different values and the ensuing relationship breakdown were central. He acknowledged resentment, explained that the original framing read as a personal attack, and apologized to Zig users who might worry about being treated similarly.

I remain unconvinced by the revised framing and bring up an older post as part of my criticism. My strongest conclusion is about how project leaders communicate with users: a public disagreement about a migration can have consequences beyond the two people involved.

I am angry about the response, and my friendship with Sumner shapes that reaction. The underlying technical question remains worth examining separately: what evidence, review and operational controls make a large AI-assisted rewrite reliable enough to ship?