Bun's Rust Rewrite Merged on May 14: 4 Canary Checks JavaScript Teams Should Run Now

Bun's Rust rewrite is merged. Good. Now ignore the language war.

On May 14, 2026, Bun merged its huge Rust port into main in PR #30412. That headline is obvious internet bait. Bun was the Zig runtime. Now a huge chunk of it is Rust. Everybody gets to post a little victory speech. None of that helps you decide whether this matters for an actual project.

What matters is what Bun's maintainer said in the PR: the canary build already passes Bun's existing test suite on all platforms, fixes several memory leaks and flaky tests, trims binary size by roughly 3 MB to 8 MB, and lands somewhere between neutral and faster on benchmarks. He also said the architecture and data structures are largely the same. So this is not Bun turning into a different runtime overnight. It is Bun trying to keep the speed while making a nasty class of bugs easier to prevent.

That is why I care. Runtime bugs are expensive in a way benchmark charts are not. If your dev server, test runner, or install flow gets less haunted, that matters more than one more screenshot of requests per second.

What actually changed on May 14

This was not a tiny cleanup. The merge pulled 6755 commits into main, and Bun exposed it immediately through bun upgrade --canary. It is still canary, though. The same PR says there is more optimization and cleanup work before this lands in a normal release.

So read this as a serious preview, not a finished migration story. If you want the vibes, the PR thread and the Reddit discussion are doing exactly what you would expect: lots of attention, lots of opinions, and not much patience for nuance.

The only sane way to evaluate this canary

If your team uses Bun already, or keeps circling it, here are the four checks worth running before you say anything confident.

1. Run your ugliest real project

Start with the repo that has the worst mix of TypeScript, codegen, postinstall scripts, watch mode, and test setup. If the rewrite is going to hurt you, it will usually show up there first.

bun upgrade --canary
bun install
bun test
bun run build
bun run dev

Do not waste your first pass on a toy benchmark app. Every team has one repo that makes tools sweat. Use that one.

2. Stress the places where runtimes usually get weird

Bun is pitching this rewrite partly as a way to catch and prevent memory bugs. Fine. Then test the paths where memory bugs and flaky behavior actually hurt: long-running dev sessions, file watching, WebSocket traffic, SQLite access, and packages with native pieces.

A decent smoke list looks like this:

• sharp image transforms

• better-sqlite3 or your normal local database path

• your largest test file in watch mode

• any server process that stays alive for more than a few minutes

• any codepath that opens a lot of files or sockets

If canary feels fine for ten seconds and then starts acting haunted after fifteen minutes, that is exactly the regression you want to catch before stable.

3. Benchmark tasks you actually wait on

I keep seeing runtime debates collapse into startup numbers that barely matter once the novelty wears off. Benchmark the stuff developers actually feel: install time, test time, rebuild time, and the scripts your CI runs all day.

hyperfine --warmup 2 "bun test" "bun run build"

If you want a clean comparison, pin stable Bun in one environment and canary in another, then run the exact same commands on the exact same project. Do not mix in unrelated dependency bumps and pretend the result means anything.

What I would watch for is not just a lower average time, but fewer ugly outliers. A runtime that is 2 percent faster on paper but 30 percent less flaky is often the better upgrade.

4. Put canary in CI before you put it anywhere important

The lowest-drama move is to add a non-blocking canary lane to CI and let it cook for a few days.

strategy:
  matrix:
    channel: [stable, canary]

steps:
  - uses: oven-sh/setup-bun@v2
  - run: bun upgrade --canary
    if: matrix.channel == 'canary'
  - run: bun install --frozen-lockfile
  - run: bun test
  - run: bun run build

You do not need a migration project yet. You need signal.

What I would not do yet

I would not switch to Bun because it is "Rust now." That is not a technical strategy. That is branding with extra steps.

I would not assume Bun's neutral-to-faster benchmark claim automatically transfers to your app. It might. It might not. The maintainer is still calling out follow-up optimization work, which is a polite way of saying the story is not finished.

And I would not skip canary testing if your app leans on native modules, long-lived processes, or weird CI containers. Those are exactly the places where runtime regressions get expensive.

My read

This merge matters, but not for the reason the discourse wants it to matter. The interesting part is not that Bun picked Rust. The interesting part is that Bun is trying to keep the same runtime shape while cutting down a category of bugs that burns real engineering time. That is a good reason to rewrite something.

So the smart move on May 16, 2026 is not to post a language-war victory lap. It is to install the canary, throw an annoying real project at it, and see whether the thing holds up. If it does, this could end up being one of Bun's most important changes even if your benchmark chart barely moves.