Theo on Bun’s AI-Assisted Rust Rewrite and Its Risks

Bun is close to my heart. I've been friends with its creator, Jarred Sumner, since I started making content, and I've supported the project through its acquisition by Anthropic. Lately, though, I've found it harder to use. OpenCode's Dax has been moving toward Node.js, citing Windows stability, Electron integration, and uncertainty about Bun's future.

Now Bun is being ported from Zig to Rust with help from AI agents. Jarred says 99.8% of the existing test suite passes on Linux x64 with glibc. What began as an experiment looks viable enough that, at the time of this video, I expect it to merge and ship—but that's my prediction, not an announcement that it has happened.

There are interesting lessons here about using AI to migrate software. There are also concerns about Bun that changing languages may not resolve. To make sense of the port, I want to separate problems with Zig, problems with Bun as a product, and the risks of rewriting a large system.

Zig is powerful, and its compile-time features let developers shape generated code in useful ways, especially when integrating with different platforms. But powerful low-level tools also leave room for mistakes. Manual memory management can lead to leaks, crashes or security problems, and supporting several operating systems adds another layer of difficulty.

I've run into memory-related problems with Bun myself, particularly in earlier releases, and Windows has been a recurring source of frustration. Bun can bundle JavaScript and its runtime into a standalone executable, which is useful for shipping tools, but applications that package it can also inherit its platform-specific problems.

OpenCode's migration is tedious partly because it used Bun-specific APIs such as Bun.file. Bun also supports Node APIs, but code written against its own interfaces has to be changed to run elsewhere. Jarred asked whether Windows stability had improved after Bun 1.3.10; in my experience, problems remained.

Dax's list goes beyond Windows. Node can be embedded in an Electron desktop application without spawning a separate process, and supporting Node makes it easier to embed OpenCode in other applications or explore Deno. Their own benchmarks did not show Bun's speed advantage materially benefiting their workload.

Bun can be excellent for package management and bundling. Its website also shows an Express benchmark of roughly 60,000 requests per second for Bun versus 20,000 for Node. That is a meaningful difference for that particular server benchmark, but it does not tell you whether a local coding agent will benefit. Measure the work your application actually does.

William Johnson's article raises another concern. Anthropic acquired Bun in December 2025 and said the project would remain open source under the MIT license, with its team continuing development. Claude Code uses Bun, giving Anthropic an incentive to keep it working, but Johnson worries that the broader ecosystem may not share all of Claude Code's priorities.

I share some of that anxiety. My assessment is that Claude Code's product experience has deteriorated, and Anthropic's own postmortem discussed problems including reduced reasoning effort, stale sessions and a prompt change. Those experiences do not prove Bun will deteriorate, but they make me question how future product decisions will be made.

The concern is not that Bun is bad or that its team has stopped caring. It's that, as the team becomes more integrated into Anthropic, issues affecting Claude Code may receive attention before issues affecting other users. I've also encountered enough package-management edge cases to consider moving T3 Code away from Bun for that use.

Imagine ten existing issues, some in the runtime used by Claude Code and some in monorepo package management. If a rewrite introduced many more issues, would the ones outside the company's main use case receive the same attention? Those numbers are a hypothetical illustration, not a count of actual defects. A community fork sounds appealing, but sustaining a runtime of this complexity is difficult.

Jarred's account of the port is that much of the code is the same, while Rust can help enforce lifetimes and provide destructors. He says he is tired of spending time on memory leaks, crashes and stability, and wants stronger tools for preventing them. I suspect supervising more people and agents makes it harder to stay close to every low-level detail; that is my interpretation of his motivation.

He says the port represents about 960,000 lines of code and that he started working on it six days earlier. He also plans a fuller explanation covering the process, performance, memory use and maintainability. Those are his claims and plans at the time of the video; the test result is encouraging but limited to the stated platform and test suite.

Bun's Zig fork had also gained parallel semantic analysis and multiple code-generation units, which the team said made debug builds faster. Jarred described Bun 1.3.14 as potentially the last Zig version if the Rust port were merged. That conditional matters: a port that passes tests is not automatically ready to ship.

Charlie Marsh asks the right question: could the team trade known issues for an unknown set of new ones? A good test suite only covers some program behaviors. Jarred says the rewrite passes tests associated with more than 200 issues and that he has not yet seen a benchmark where it is slower; those observations still need broader verification.

The port is intended to preserve the existing implementation, with few third-party libraries and without adopting async Rust wholesale. Rust's ownership and borrowing rules can help prevent classes of memory errors in safe code. They do not eliminate every bug or memory leak, and unsafe code requires the programmer to uphold additional safety conditions.

I looked at unsafe usage as a rough signal. In the Rust-based uv project, my initial search found 165 occurrences, including comments; a narrower search for a particular unsafe-block spelling found about 73. That is a crude text search, and different search patterns do not give a reliable comparison of all unsafe operations.

My search in the Bun port returned 13,044 occurrences of the word unsafe. That is a count of text matches, not a verified count of unsafe blocks or defects. It caught my attention because a close translation of low-level Zig can carry its existing assumptions into Rust rather than immediately becoming idiomatic safe Rust. The count alone cannot establish how risky the code is.

One possible path is to find a troublesome unsafe function, understand its invariants and gradually replace parts with safe abstractions. An agent can use compiler diagnostics as feedback during that work. Passing the compiler is useful evidence, but it does not by itself prove the migration is behaviorally correct or that all surrounding unsafe assumptions are sound.

The TypeScript team's port of its compiler to Go offers a useful comparison. The initial approach aimed to preserve the existing implementation closely, even when the result was not idiomatic Go, and gained speed from a native executable. Further optimization could then take advantage of Go's strengths. Preserving behavior first can be a practical migration strategy.

This changes how I think about languages: they can be tools for producing an executable, rather than identities a team has to adopt completely. The Bun team loves Zig; Rust offers tools that may help with the bugs it wants to address. AI can make a repetitive port more feasible, while tests, measurements and human judgment remain essential.

Jarred also describes a difficult layering problem. Splitting the port into many Rust crates helps compilation and could make components reusable, but crate boundaries prevent cyclic dependencies. Bun's Zig code uses tagged pointers for interfaces in places such as event-loop tasks, process-exit callbacks and nonblocking file I/O.

He is concerned about the overhead of particular trait or function-pointer approaches and whether the compiler can optimize them in this design. The current approach uses generated declarations and link-time optimization to turn tagged dispatch into direct calls where possible. He asked experienced Rust developers for a cleaner solution with little runtime or memory overhead; this is a specific engineering tradeoff, not a universal claim about all Rust traits.

Compilation time, module boundaries and low-level performance remain hard problems even when agents can generate code quickly. Jarred is learning and discussing the design in public. I respect how ambitious the experiment is, but the size of the port and its extensive unsafe usage make careful review important.

Jarred says he would not merge the Rust port unless performance, memory use and stability were measurably better than the Zig implementation, with stability the priority. I trust him and want the team to succeed. At recording time, I expect benefits and new issues alike; the outcome remains to be seen, and there is a lot to learn from the attempt.