Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16905 > unrolled thread

Bun Zig Rust AI rewrite

Back to article view | Back to comp.programming

Contents

  Bun Zig Rust AI rewrite ram@zedat.fu-berlin.de (Stefan Ram) - 2026-07-13 09:31 +0000
    Re: Bun Zig Rust AI rewrite cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-13 09:57 +0000

#16905 — Bun Zig Rust AI rewrite

| The recent buzz surrounding the JavaScript runtime Bun is centered on
| its massive, rapid architectural pivot: the entire runtime was
| rewritten from Zig to Rust in just 11 days using AI agents.
| 
| The transition culminated in the release of Bun v1.4.0, making it the
| first production-ready release powered by the new Rust codebase.
| 
| Why the Shift from Zig to Rust?
| 
| Bun's creator, Jared Sumner, initially downplayed the rewrite as a
| temporary experiment, but later confirmed a permanent migration. The
| core motivations include:
| 
| Systemic Memory Safety   The team grew exhausted from tracking down
| tedious memory leaks, crashes, and stability problems.
| 
| Compile-Time Guarantees   Zig lacks RAII-style Drop semantics. The
| team moved to Rust so the compiler's borrow checker and Drop traits
| could natively enforce type lifetimes and prevent memory bugs.
| 
| Upstream Tension   Reports indicate that Bun was maintaining a highly
| customized fork of Zig to support AI-generated features, creating
| friction with the core Zig maintainers when those features couldn't be
| merged upstream.
| 
| The "Speed of AI" Rewrite Process
| 
| Because Bun was acquired by Anthropic in late 2025, the team had
| unique access to cutting-edge AI orchestration.
| 
| 11 Days, 1 Million Lines   Using a pre-release version of Claude Fable
| 5 and 64 parallel AI agents, the team ported over a million lines of
| code in under two weeks. This would traditionally take three engineers
| a full year.
| 
| Adversarial Review   The architecture utilized dynamic workflows where
| "adversarial" AI review agents were tasked with aggressively poking
| holes in and rewriting the code generated by other agents.
| 
| The Price Tag   The sheer volume of tokens consumed during the
| multi-agent feedback loop cost a staggering $165,000 in API token
| fees.
| 
| Concrete Results of Bun v1.4.0
| 
| Despite fears that the automated port would result in "AI slop," the
| performance metrics for the Rust-backed Bun v1.4.0 have proven highly
| successful:
| 
| Bug Fixes   The rewrite automatically resolved 128 legacy runtime bugs
| and memory leaks.
| 
| Massive Memory Drop   In a benchmark testing 2,000 parallel builds,
| memory usage plummeted from a bloated 6.7 GB down to a stable 609 MB.
| 
| Smaller & Faster   The binary size shrank by roughly 20% (about 3 to 8
| MB lighter per platform), and HTTP throughput improved by 2% to 5%.
| 
| Community and Developer Backlash
| 
| While the performance upgrades are real, the method of delivery
| sparked heavy debate across the software engineering community:
| 
| The Death of Human Review   Critics on Hacker News and Lobsters argue
| that a closed-loop system where AI writes and AI reviews code means
| "no human has actually read the codebase in its entirety," making
| future manual debugging near impossible.
| 
| "Unsafe" Rust Concerns   Early code leaks showed a heavy reliance on
| static mut and thousands of unsafe blocks to preserve Zig's original
| raw pointers, leading to arguments over whether the code is truly safe
| or idiomatic.
| 
| The Blow to Zig   Bun was arguably the most high-profile production
| project built in Zig. While the Zig community acknowledges that
| startup tech debt evolves, losing Bun to Rust is seen by some as a
| blow to Zig's marketing footprint.

[toc] | [next] | [standalone]

#16906

In article <bun-20260713102858@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> [snip]
>| Despite fears that the automated port would result in "AI slop," the
>| performance metrics for the Rust-backed Bun v1.4.0 have proven highly
>| successful:
>| 
> [...]
>| 
>| "Unsafe" Rust Concerns   Early code leaks showed a heavy reliance on
>| static mut and thousands of unsafe blocks to preserve Zig's original
>| raw pointers, leading to arguments over whether the code is truly safe
>| or idiomatic.
> [snip]

The bigger problem, pointed out externally, was not the use of
`unsafe` (that can be ok), but rather that the rewrite had
multple prominent instances of unsound memory accesses, and
villated violating the _language's_ rules and memory safety
generally.  Critically, many were easily triggered from _safe_
Rust code; this is supposed to be a compile-time error.

People misunderstand what "unsafe" means in Rust: it does not
mean you can do whatever you want.  It merely means that the
responsibility for upholding the invariants required by the
language shifts to the programmer, who for some reason knows
that a given construct does not violate the language's rules,
while the compiler cannot infer this.  The Bun port ignored
this, in part because the Bun authors (by their own admission)
did not know Rust when they started.  It's telling that they did
not even bother to have an agent run the test suite with `miri`,
which might have detected many of the problems.

Does the rewrite "work", in so far as the bun test suite passes?
Yes.  Will it silently break and stop working on a minor
toolchain update?  Probably, also yes.

Note that this also speaks to the limitations of testing, and
far from being a success story of LLM use, is actually a good
example of AI slop.

	- Dan C.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web