Jarred Sumner just announced that Bun's JavaScript runtime has been rewritten from Zig to Rust, and 99.8% of the existing test suite passes. This is not a typical language wars argument—it's a founder with a production codebase making an empirical call about tooling.
The stated reason for the rewrite: "I am so tired of worrying about memory leaks and crashes and stability issues."
That's refreshingly honest. Bun is a performance-focused JavaScript runtime that competes with Node.js and Deno. It's built on low-level systems programming, where memory management bugs can cause crashes, data corruption, or security vulnerabilities.
Zig is designed to give programmers explicit control over memory allocation without the safety guarantees of Rust's borrow checker. That control enables optimization but requires perfect discipline from developers. One mistake—a use-after-free, a double-free, a buffer overflow—and you have a critical bug.
Rust trades some of that control for compile-time guarantees. The compiler enforces memory safety through the borrow checker, which prevents entire classes of bugs that are common in C, C++, and Zig. If your code compiles, certain types of memory errors literally cannot happen.
The trade-off is that Rust is harder to learn and sometimes requires restructuring code to satisfy the compiler. Developers joke about "fighting the borrow checker," but that fight is the compiler preventing bugs that would otherwise ship.
Sumner's comment about "ugly parts looking uglier" is telling. Rust requires marking unsafe code explicitly with the unsafe keyword. This makes potentially dangerous operations visible, which "encourages refactoring"—meaning developers are motivated to minimize unsafe code because it stands out.
The 99.8% test pass rate is impressive for a rewrite of this scale. Bun has thousands of tests covering JavaScript runtime behavior, which is complex and full of edge cases. Getting that close to full compatibility suggests the Rust version is functionally equivalent to the Zig implementation.
When asked about compile times, Sumner noted they're "basically the same" as Zig using their faster custom Zig compiler fork. With the upstream Zig compiler, Rust would actually compile faster. That's significant because slow compile times are a common criticism of Rust.
This rewrite isn't happening in a vacuum. Discord famously rewrote performance-critical services from Go to Rust and saw latency improvements. Cloudflare uses Rust for infrastructure services. Microsoft and Amazon are investing heavily in Rust for systems programming.
The pattern is consistent: teams start with languages that are easier to write quickly (Go, Python, JavaScript), hit scaling or reliability issues, and either optimize heavily or rewrite in Rust. The calculus changes when stability bugs cost real money or user trust.
What makes the Bun case interesting is that Zig is already a performance-focused systems language. This isn't "we rewrote Python in Rust for speed." It's "we rewrote Zig in Rust for safety," which is a different argument.
The question for other projects is whether the safety guarantees justify the migration cost. Rewriting a codebase from one low-level language to another is expensive and risky. You're betting that the reduction in stability issues outweighs the development time invested in the rewrite.
Sumner's bet is that Rust's compiler will catch bugs that would otherwise require extensive debugging in production. For a JavaScript runtime that developers depend on, that's probably the right call.
Language choice debates are usually religious arguments with no clear winner. This is different. It's a maintainer saying, "I shipped a working product in Zig, and I'm rewriting it in Rust anyway because the long-term stability matters more than the short-term migration pain."
That's data worth paying attention to, especially if you're making similar architectural decisions. The technology works in both languages. The question is which one lets you sleep better at night knowing your code won't crash in production.
