After Bun’s Rust rewrite surfaced, the internet did what the internet does best: it started picking teams.

One side read it as “see, Zig was never enough.” Another side read it as Rust people getting smug again. Somewhere in the middle, developers grabbed popcorn and waited for the next language holy war to catch fire.

Mitchell Hashimoto’s point is sharper than that, and much more worth keeping. He is not saying Bun should not move to Rust. He is not simply defending Zig either. His real criticism is this: there were many positive and technically interesting stories Bun could have told here, but Bun leadership did not steer the conversation early enough, so the discussion slid into anti-Zig mud.

That is the missed opportunity. The interesting part is not “which language won.” The interesting part is that Zig helped Bun get this far, programming languages may be getting less sticky for large products, and memory safety is only one layer of a much deeper engineering-practice question.

Clawd whispers:

Language wars are attractive because they are easy to argue. Rust is safe. Zig is flexible. C++ veterans never die. Go engineers leave work on time. The problem is that this kind of argument often has very low information density. Lots of metal clanging, not many screws actually turning.

(・∀・)

Zig was not the loser. It was the scaffolding that got Bun here

The Bun PR itself is substantial. In oven-sh/bun#30683, Jarred Sumner removed the remaining 1,290 Zig files, renamed $zig(…), $newZigFunction(…), and the JS2Zig__ prefix to Rust equivalents, and moved codegen paths from .zig to .rs. This is not a cosmetic rename. It is the final cleanup of a deep runtime migration.

The easy thing to forget is that if Zig had been useless, Bun would not have reached this point with it.

Bun is not a toy. It is a JavaScript runtime, package manager, bundler, test runner, and a whole developer-tool stack wrapped together. A project that pressures the JavaScript tooling ecosystem at that level did not get there by accident. Zig played a real role in that story.

Mitchell’s suggested framing is simple: Bun leadership could have said that first. Acknowledge what Zig made possible in the early phase, then explain why the next phase needs Rust’s memory-safety guarantees and ecosystem conditions. That is not PR sugar. That is technical history done responsibly.

Without that framing, the internet fills in the cheapest version: Rust won, Zig lost. It is satisfying, but it is dumb.

The bigger shift: language lock-in is weakening

Programming languages used to feel almost like marriage vows. Once a project chose a language, the next decade was often shaped by that choice. Rewrites were too expensive, team skills were too fixed, and the tooling stack was too heavy. The language was not a module. It was the foundation.

Bun makes that assumption feel less permanent.

Mitchell’s sharper observation is that people may think Bun moving to Rust is a win for Rust, but Bun also showed something more unsettling: it can apparently move a major product narrative from one systems language to another very quickly. Rust is useful until it is not. Another language could become useful later.

That does not mean rewrites are cheap now. Large rewrites are still expensive, especially around runtimes, FFI, codegen, and test matrices. But AI coding, stronger type systems, test coverage, codegen, and interop are slowly weakening the idea that a language choice is destiny.

Languages are starting to look more like replaceable parts and less like religious identity.

That is a more valuable observation than Rust versus Zig. It changes how engineering organizations think about technology selection. The question becomes less “which language is best?” and more “which language gives the best tradeoff for this product phase, risk model, and team shape?”

Clawd chimes in:

A decent analogy is a startup using Notion to run the whole company, then later moving parts of the workflow to Linear, GitHub Issues, or internal tools. Notion did not become trash. It completed one phase of the job. Replacing a tool is not the same as disproving it.

Memory safety is not magic. It is a set of boundary guarantees

Rust’s strongest card in this discussion is, of course, memory safety. Bun has dealt with crashes, native boundaries, runtime complexity, and all the wonderful ways low-level software can ruin an afternoon. Rust’s type system and borrow checker really can move many runtime explosions into compile-time failures.

But the lazy version, “Zig was unsafe, so Bun moved to Rust,” is too flat. A newer developer can read the real question as a stack of repair jobs:

  • An allocator is the warehouse manager for memory. If the ledger is wrong, code can pick up a shelf that was already cleared out.
  • FFI is the customs checkpoint between languages. If the two sides disagree about shape, ownership, or lifetime, the package may explode after crossing the border.
  • A JIT boundary is like paving the road while cars are already driving on it. The machine code appears during runtime, so the crash may show up far away from the original mistake.
  • Concurrent state is many people editing the same whiteboard at once. Without rules, someone erases another person’s fresh note.
  • An API contract is the promise between two pieces of code. If callers assume a promise the callee never made, that assumption becomes a future incident.

Rust can turn some of those mistakes into compiler errors, which is a huge deal. But it does not make every class of incident disappear. The useful questions are more specific: where did Bun crash most often, which bugs would Rust actually block, and which ones still need tests, review gates, architecture boundaries, or better process?

If Bun can publish the crash categories, before-and-after incident patterns, testing strategy, and the bug classes Rust now blocks, this story becomes a postmortem the whole systems-language world can learn from.

Developer-tool companies sell trust, not just features

Developer-tool companies are unusual. If a consumer app changes its internals, most users care only whether it is faster, stabler, or cheaper. But developers care how the team thinks. Adopting a tool often means wiring it into CI, deployment, local machines, team habits, and several years of future technical debt.

So the technical decision itself becomes a trust signal.

When Bun leadership does not define the story, the internet defines it instead. The internet rarely picks the fairest version. It picks the version with conflict: enemies, winners, losers, teams. That gets short-term attention, but it can weaken long-term trust.

A stronger message would have been simple: Zig gave Bun early speed and control; Rust is the next-phase choice for stability and maintainability; a language migration means the product’s risk model changed, not that the previous language was a historical mistake. That version is not boring. It is more mature, and it is more convincing.

Clawd , seriously:

Developer audiences can handle big changes. Developers refactor messy systems for a living. The worrying part is not the rewrite. The worrying part is when a team talks about a rewrite like it is dunking on the previous technical choice. That makes adopters wonder: is the current choice the next one to be dunked on?

Closing

Bun moving from Zig to Rust can absolutely be turned into a language war. The internet always has demand for that. Feed it one PR and it prints ten factions.

But Mitchell’s useful reminder is that strong technical communication should move readers one level higher, not let the discussion fall back to the easiest faction fight.

Zig does not need to be framed as the loser. Rust does not need Zig to be mocked in order to be a good choice. What Bun can teach is how a large product rebalances speed, stability, memory safety, and engineering discipline. It can also teach how a developer-tool company should frame a controversial technical decision before the conversation frames itself.

Languages can change. The narrative stays.

If a company turns a rewrite into a postmortem, the whole community gets smarter. If it only becomes a language war, it is just another loud night market debate: lots of heat, not much light.