Jarred Sumner opened PR #30412 six days ago with a three-word title: “Rewrite Bun in Rust.” The pull request passes Bun’s full pre-existing test suite across all platforms, fixes several memory leaks and flaky tests, and shrinks the binary by 3 to 8 MB. Benchmarks are, in Sumner’s characterization, “between neutral and faster.” You can install it today via bun upgrade --canary.
This is not a fork. It is not a community contribution. Sumner is Bun’s creator and maintainer, and he is replacing the Zig codebase he spent years building with a Rust one that preserves Bun’s existing architecture and data structures.
Why Rust, why now
The PR description is direct about the motivation. Sumner writes that memory bugs have “costed the team an enormous amount of development & debugging time over the years,” and that Rust’s compiler-assisted tools for catching and preventing those bugs are the primary benefit. Not performance. Not ecosystem. Safety, specifically the class of safety that costs maintainer hours when it fails.
The rewrite uses no async Rust and few third-party libraries. This is a narrow, architectural swap: same data structures, same external behavior, different systems language underneath.
Six months ago, Anthropic acquired Bun. At the time, Bun had 7.2 million monthly downloads and zero revenue. Anthropic uses Bun as the infrastructure for Claude Code, the Claude Agent SDK, and planned AI coding products. A runtime with memory leaks and flaky tests is a liability when your parent company ships it as the foundation of a developer tool used in production. The Rust rewrite is, among other things, a reliability investment that aligns with Anthropic’s interests.
The Electrobun dependency chain
Electrobun is a desktop application framework that uses Bun as its main-process runtime, with native bindings written in Objc, C++, and Zig. Per its GitHub repository, Electrobun claims 14 MB bundles, sub-50ms startup, and 15 to 30 MB memory usage by using system WebViews instead of bundling Chromium, compared to Electron’s 150 MB+ bundles and 2 to 5 second startup.
Electrobun has not announced a version 2.0, a Rust rewrite, or any plan to decouple from Bun. Its README and documentation still list Bun as the runtime. But Electrobun’s Zig native bindings sit on top of a Bun core that is now rewriting itself in Rust. When Bun finishes the Zig-to-Rust transition, every downstream project with Zig bindings layered on the Bun API will need to evaluate whether those bindings still work against the new core, and whether to follow Bun to Rust or maintain a divergent integration path.
This is the pattern worth watching. Bun is not the only JavaScript toolchain component built in Zig. If Bun’s own creator concluded that the memory-safety tooling in Zig was insufficient for a production runtime under real load, maintainers of smaller Zig-dependent projects face the same calculus with fewer resources.
What the rewrite preserves
Bun’s current stable release, v1.3.14, includes built-in PostgreSQL, MySQL, and SQLite drivers, a Redis client, an S3 client, a frontend dev server, single-file executable compilation, and a Jest-compatible test runner. The Rust rewrite targets all of these. Sumner’s PR states that the existing architecture is preserved, which means the external API surface (the JavaScript and TypeScript interfaces developers actually call) should remain stable.
For teams currently using Bun in production, the immediate question is whether the canary build passes their integration tests. The PR claims the full pre-existing test suite passes, but Bun’s test suite is not your test suite. The binary is smaller and benchmarks are neutral-to-faster, but those benchmarks measure Bun’s internal regressions, not the behavior of applications built on Bun.
The practitioner calculus
The Rust rewrite changes the evaluation for teams choosing a JavaScript runtime today in two ways.
First, Bun is now a runtime in transition. Its internals are being rewritten while its stable channel continues to ship Zig-based builds. Bug reports against the current stable may be addressed in a codebase that is being replaced. Feature requests may land in the Rust branch first. Teams on Bun need to decide whether to track canary or wait for stable, and either choice carries a different support profile.
Second, the Anthropic acquisition gives Bun a financial backer with a specific interest in reliability. That is a strength. It is also a concentration of dependency: Anthropic’s AI tooling depends on Bun, and Bun’s development priorities will inevitably reflect that dependency. Teams using Bun for non-AI workloads should expect that the roadmap serves Anthropic’s needs first, and the broader ecosystem second.
For desktop framework maintainers specifically, the Electrobun pattern is instructive. Electrobun chose Bun for its main process and Zig for native bindings. Both of those choices are now in flux. The framework still works, the README still says Bun, and nothing has broken yet. But the runtime is moving from Zig to Rust, and the native-binding layer shares a language with the runtime’s outgoing implementation. That is a coupling worth auditing in any project that depends on Bun’s native interface.
Frequently Asked Questions
How does Electrobun compare to Tauri, not just Electron?
Tauri produces ~25 MB bundles with ~500ms startup, versus Electrobun’s claimed 14 MB and sub-50ms. Both avoid bundling Chromium by calling system WebViews (WebView2, WebKitGTK) at runtime. The practical difference: Tauri is already Rust-native with no Bun dependency, so it faces no migration risk from this rewrite. Electrobun’s smaller footprint comes with a runtime that is actively swapping its systems language.
Which Bun features carry the most regression risk in the Rust build?
The built-in PostgreSQL, MySQL, and SQLite drivers are implemented in the native layer, not in JavaScript. Connection pooling, prepared-statement caching, and large result-set handling all depend on memory management that changes when the underlying systems language changes. Drivers that interact with external services have failure modes (timeout behavior, encoding edge cases, reconnection logic) that synthetic test suites rarely exercise.
Will Anthropic prioritize the Bun features most teams rely on?
Anthropic’s products (Claude Code, Agent SDK) primarily need fast startup, low memory overhead, and native file system access. Features like the built-in S3 client, frontend dev server, and Jest-compatible test runner serve general-purpose Node.js replacement use cases that are less central to Anthropic’s AI tooling. The passing test suite confirms API compatibility, but test coverage depth may not be uniform across all features.
What does ‘no async Rust’ mean for projects with native bindings to Bun?
Bun is built on the JavaScriptCore engine, which provides its own event loop. Adding a Rust async runtime on top would introduce a competing event loop and complicate the C FFI boundary that external bindings use. By restricting the rewrite to synchronous Rust, the external C API surface stays more predictable. Projects binding to Bun through that C layer, like Electrobun’s Zig bindings, face a more stable interface contract than if async patterns had been introduced.