The Great Bun Rewrite

Summary (tech-focused)

• Bun’s “rewrite” from Zig to Rust timeline (as described):

  • Bun’s creator initially framed the work as a fun experiment, not an immediate committed decision to rewrite the whole project.
  • Within a short period, the project escalated quickly: what started as a port effort turned into a production-level Rust rewrite.
  • The speaker claims the rewrite process took 11 days, aided by Claude-based (LLM) tooling and pre-release access (“before all of us plebs…”).

• Why Bun sought Rust instead of staying with Zig (core technical rationale):

  • Bun’s Zig experience is described as challenging due to memory safety and stability issues (e.g., use-after-free, out-of-bounds, double free, memory leaks, and race conditions).
  • The speaker attributes difficulty to handling unusual mixes of GC (garbage collection) with manually managed memory, which the speaker says is uncommon and not something languages like Zig/Rust were designed to make easy.
  • The key argument: Rust’s memory-safety guarantees are enforced by the compiler, rather than relying on:
    • style guides, and
    • best-effort enforcement via code reviews / linters / static analyzers.
  • Additional context: the Bun codebase reportedly includes a substantial amount of C++ (about 20%), and the speaker argues this makes style-guide enforcement harder to maintain.

• LLM cost/compute discussion:

  • The rewrite’s quoted token spend was extremely large: approximately $165,000 in API pricing.
  • The speaker challenges the “that’s wasteful” take by comparing it to real-world rewrite costs:
    • He cites prior experience with an internal Netflix rewrite that took ~1 year with multiple staff engineers and broader coordination overhead.
    • He argues that $165k for speed (11 days) can be relatively reasonable compared to multi-month/year team cost (including opportunity cost like feature freeze).
  • The “three-point triangle” framing implies the rewrite was aimed at optimizing cost + quality + speed simultaneously.

• How the rewrite was executed (LLM/agent workflow + testing strategy):

  • Stepwise agent loop with reviews:
    • The process described includes taking a change/task, then requesting two separate reviews of the change set.
    • The reviews are performed by separate agents with no context, focusing on whether the change does what it should and on bug-finding.
  • Mechanical translation approach:
    • The LLM would translate one Zig file to one Rust file, then run the review/fix loop.
  • Error-driven iteration:
    • After translation, the speaker claims there were about 16,000 errors.
    • Multiple agents worked in parallel across different work trees/shards, each handling one error at a time, then re-reviewed and iterated until resolution.
  • Build/link + unit-test gating:
    • After initial compilation attempt, there were linker errors, followed by another large parallel phase to make unit tests pass.
    • The system is described as distributing test fixes across many workers until all tests passed.
  • Scale metrics (as stated):
    • End state after 11 days: 6,502 commits, about 1.8 million lines written/rewritten, and the $165k cost.

• Product/release impact speculation:

  • The speaker emphasizes uncertainty around the upcoming Bun 1.4 public release:
    • Potential outcome: if the rewrite has regressions, updating could break CI/production workflows for many users.
    • Alternative outcome: it works smoothly and looks “pretty cool.”
  • The implied “risk” is that a widely used runtime gets updated with behavior/build changes.

• Reviewer’s/host’s takeaways (tooling angle):

  • The speaker is particularly impressed by the developer-tooling pattern: using LLM agents to drive reviews and fixes in a structured workflow.
  • Mentions a tool/workflow they built (“Prime Agent review”) that can:
    • generate URLs,
    • include specific context files,
    • accept prompts and review modes,
    • then output usable PR review feedback.
  • Overall theme: dev tools + agentic review loops are an especially strong LLM use case.

Main speakers / sources

• Speaker/host: Jared (Bun creator / author) is referenced and discussed throughout; the primary commentary is from the YouTube host (unnamed in subtitles) who analyzes the blog post and workflow.
• Source document: the Bun blog post explaining the “why and how” of rewriting from Zig to Rust.
• AI tooling referenced: Claude / “Claude code” and Claude-based workers/agents (LLM-assisted coding and review).