How “done” is Bun’s Rust rewrite, really? A reality check

Ever seen a software rewrite get announced with movie-trailer energy, only to find that nothing feels “shipped” in the real world? That’s the particular itch Bun’s “rewrite Bun in Rust” story scratched for a lot of engineers: impressive engineering claims up front, then a long pause before the user-facing benefits show up.

This post is a technical reality check on what “going well” can mean for a rewrite like Bun’s, where the headline is language change (Zig → Rust), but the lived experience is release timing, CI behavior, and safety work that doesn’t make good marketing copy.

The headline: a Zig → Rust rewrite driven by agent workflows

Bun’s own blog post, published July 8, 2026, describes a “Rust rewrite” that landed by merging into main (not as a new release tag) after the existing Bun test suite reached 100% passing across platforms. (bun.com)

The author describes using a pre-release “Claude Fable 5” model as part of Claude Code’s dynamic workflows—loops that generate code, run builds/tests, and iterate until the failures stop. ()

Key numbers from the post:

• The pre-merge rewrite phase ran from “May 3 → merged May 14” and included 6,778 commits. ()
• The token-based cost (at API pricing) was reported as about $165,000, including 5.9B uncached input tokens, 690M output tokens, and 72B cached token reads. ()
• The workflow scaled to 64 Claude instances at once (“dynamic workflows kept 64 Claudes running for 11 days”). ()

From a beginner’s perspective, that last point matters: this wasn’t “one prompt, then hope.” It was a feedback loop. A lot of engineering time still goes into designing the loop so that the model can’t wander off into plausible-but-wrong code.

Why the language change was about stability, not vibes

Bun’s blog post spends real time explaining the stability pain that comes from manual memory management. In plain language:

• Use-after-free means code keeps using a pointer after the memory has been released.
• Double-free means the same memory is released twice.
• Memory leaks mean allocated memory is never released.

Those failures show up particularly hard when a runtime mixes garbage-collected JavaScript (where the engine manages memory) with native code that must free memory explicitly.

Rust is introduced as a way to tighten the feedback loop. In Rust’s model, ownership and borrowing are checked by the compiler. That gives you earlier errors for many lifetime mistakes, instead of delayed crashes. Rust also uses RAII (Resource Acquisition Is Initialization): resource cleanup is tied to scope exit, and the compiler arranges cleanup via the Drop trait. ()

The blog’s comparison table is effectively the pitch: Zig uses defer, Rust relies on Drop. ()

And yes, Rust isn’t magic. The same post later notes that a few percent of the Rust code sits inside unsafe blocks. unsafe is Rust’s escape hatch that tells the compiler “trust me,” so the borrow checker and other guarantees don’t apply there. ()

“Merged to main” is not the same thing as “released”

This is where the engineering vs marketing gap shows up most.

A Git tag (often used for release versions) is a marker in the repository’s history that typically corresponds to something end users can install. In contrast, merging to main means the code changes are present in the repo, but not necessarily bundled into a versioned artifact.

Bun’s rewrite merged into main on May 14, 2026 per the blog timeline (“May 3 → merged May 14”). ()

But if you look at Bun’s GitHub releases list, the most recent tag shown there is Bun v1.3.14, released May 12, 2026. (github.com)

So the question many readers implicitly ask (even if they don’t phrase it this way) becomes: how much rewriting did it take before the rewrite became a thing users can actually install and trust? That’s the crux of “Is it going?”

A long gap doesn’t automatically mean failure. Release engineering has boring reasons:

• stabilization after a large internal change,
• compatibility verification against the Node.js ecosystem,
• security review,
• and performance tuning.

But it does mean hype-style statements like “done” should be treated carefully until there’s a corresponding release cadence.

What “verification” looks like after the merge

One of the more technical and less glamorous sections of Bun’s blog is what happens after the merge: security review rounds and fuzzing.

The post claims that after merging the Rust port, Bun completed 11 rounds of security review from Claude Code Security, and then added 24/7 coverage-guided fuzzing for parsers (JavaScript, TypeScript, JSON variants, CSS, Markdown, etc.). A fuzzer here is a program that automatically throws lots of semi-random inputs at code to provoke crashes or logic errors; coverage-guided fuzzing means the fuzzer tries to increase which code paths it triggers, so it doesn’t only hit shallow bugs. ()

The blog further says the fuzzing executed the parsers 100 billion times, leading to roughly 15 PRs so far. ()

That combination matters, because it changes what “the rewrite worked” means. Passing a test suite in CI is necessary, but it’s not the whole story. For code that touches parsers and runtime APIs, crashes and mis-parses often hide behind the exact input shapes that a typical unit test suite never generates.

A quick method to sanity-check “progress” in any rewrite

When a project claims an enormous rewrite, “progress” becomes measurable if you track signals that can’t be hand-waved away.

For Bun specifically (and many similar repos), a practical approach is:

1. Release tags and release notes: do versioned artifacts update on a believable schedule? (Bun’s latest tag visible in GitHub’s release list is v1.3.14 from May 12, 2026.) ()
2. Post-merge work described technically: security review rounds, fuzzing additions, CI/sharding behavior, and the kinds of bug classes targeted. ()
3. Evidence that the safety net is still actively running: fuzzers, sanitizers, and CI pipelines are ongoing costs. Even when they don’t “finish,” they usually leave traces in the repo through new fixes.

That still leaves uncertainty—because a lot of “work” can occur inside CI logs, infrastructure, and internal dashboards rather than visible code changes. But it’s harder to dismiss than “the model said it was correct.”

The side-quest question: are other agent projects also moving?

The Bun rewrite wasn’t an isolated event; it’s part of a bigger narrative about agentic development. A reasonable skeptic’s move is to check other repos that were public experiments and see whether they’re still actively shipping.

For example:

• The Anthropics claudes-c-compiler repository shows its latest commit on Feb 5, 2026. (github.com)
• The wilsonzlin/fastrender repository shows its latest commit on Jan 18, 2026. (github.com)

These dates don’t prove anything by themselves. A project can pause because it’s done, because it’s being reworked privately, or because focus moved. Still, they undercut the “everything is accelerating” vibe when you look at public development velocity.

So, is Bun’s Rust rewrite “going”?

It’s going in the sense that the rewrite was reported as merged into main after achieving 100% test suite passing across platforms, using a large agent workflow and heavy verification. ()

It’s also going in the sense that the follow-on work described is explicitly about safety and correctness: multiple security review rounds and 24/7 coverage-guided fuzzing. ()

But it’s not “going” in the user-visible sense implied by some hype: as of the latest release tag visible in the repo’s release list, Bun v1.3.14 (May 12, 2026) is still the last tagged release. ()

That mismatch between internal confidence and external release cadence is exactly why careful engineers stay Canny: the engineering work may be real, but “done” needs the boring artifacts—version tags, release notes, and time-to-fix under real-world usage—to become undeniable.

The quiet lesson from rewrites

A rewrite is not a checkbox. It’s a long sequence of coupling problems:

• language semantics,
• memory and lifetime rules,
• API compatibility,
• performance regressions,
• and the long tail of inputs that only fuzzing and production usage expose.

Agent tools can accelerate the first big chunk: translation, scaffolding, and getting the code to compile and pass basic checks. But after that, the rewrite becomes a verification marathon, and verification doesn’t end just because a dashboard turns green once.

That’s the part hype stories often flatten. The technical story is still unfolding in the gap between “merged” and “released,” and in the safety work that keeps running after the merge button gets pressed. ()