I wish this was clickbait

Overview / context

• The video argues that Bun’s future is uncertain, largely due to:
  • Stability concerns (especially on Windows)
  • Product dependency risk after Anthropic acquired Bun (Dec 2025)
• A key theme is that Bun’s original promise has been strong, but recent real-world pain is pushing some teams to consider alternatives—notably moving from Bun to Node.js.

Evidence of ecosystem pressure / reviews & migration decisions

• Dax (Open Code) reportedly decided to move from Bun to Node.js, citing:
  • Better stability on Windows with Node
  • Electron compatibility (Bun’s process/spawning model wasn’t ideal)
  • Avoiding the need to spawn separate processes
  • Uncertainty about Bun’s long-term future
• The narrator also cites a William Johnson article about Bun’s future (linked in the video description).

What’s driving Bun’s technical shift: “Bun in Rust”

• Bun is described as having historically been tied to Zig (including a fork relationship).
• The video claims the project is now rewriting Bun in Rust, framed as a path that started as a “fun side project” but became the more viable approach.

Stated progress / claims

• 99.8% of Bun’s existing test suite reportedly passes in the Linux x64 build for the Rust rewrite.
• The rewrite is described as a large “line-by-line port”, rather than a fully idiomatic Rust redesign.
• The scope is described as a massive rewrite—about 960,000 lines of code.
• A Rust-backed release is mentioned: Bun 1.3.14 (positioned as a milestone tied to the Zig fork era, plus faster internal builds).

Zigg/Zig issues that motivate change

• The video outlines problems in the Zig ecosystem:
  • Powerful compile-time customization can become “foot guns.”
  • Zig is not inherently memory-safe, potentially leading to memory leaks and security risks
  • Cross-platform complexity (Linux-origin → Windows) and reported Windows-related problems encountered by Bun

Bun features affecting downstream tools

• Bun’s standout capability: easy bundling into a single executable by including Bun plus app code.
• The video connects this to downstream tooling—e.g., Claude Code and Open Code built around shipping Bun executables.

Coupling risk

• If Bun breaks, dependent tools break, especially when they bundle Bun directly.

Benchmarks / performance framing

• The narrator argues Bun’s performance advantages are sometimes overestimated, particularly for server-style runtime loads.

Example (Express)

• Roughly 20k req/s on Node → 60k req/s on Bun (about 3×), but noted at that request scale.

Where Bun is said to be strongest

• Package management
• Bundling/distribution workflows
• Local dev bundling

Where Node is “good enough”

• For high-throughput servers, Node performance is described as sufficiently strong relative to Bun’s gains.

Concerns about the Rust rewrite: risk, unsafe, and prioritization

The video acknowledges potential benefits but focuses heavily on risks.

1) “Unsafe” in Rust port

• The rewrite is not described as fully “safe Rust.”
• The video examines how much unsafe exists in the codebase:
  • 13,000+ instances of unsafe calls are claimed (near the midpoint of the rewrite).
  • Reasoning: because it’s largely a port of Zig code, the Rust implementation likely uses unsafe to preserve behavior and bypass borrow-checker constraints.
• The narrator discusses that borrow-checker enforcement would ideally reduce crashes/memory bugs, but doing so requires progressively pushing unsafe downward and refactoring over time.

2) Unknown bug categories from a full rearchitecture

• The narrator argues a rewrite can trade:
  • known issues in the current Bun implementation
  • for unknown issues introduced by the new architecture
• Worry: the team may prioritize fixes impacting the top product paths (e.g., Cloud Code / agent bundling paths), leaving other Bun users with slower remediation.

3) Rewrite scope vs. test coverage

• Even with passing tests, the narrator emphasizes that tests cover only subsets of real behavior.
• Framing: “200 known issues vs unknown unknowns.” This is presented as a core fear.

AI-tools / feedback loop argument

• The video argues Rust offers a better feedback loop for AI agents:
  • Rust compile errors are described as extremely informative
  • In theory, an agent can respond to compiler diagnostics (e.g., fixing lifetime or memory-safety constraints)
• This is contrasted with debugging workflows where reproducing issues may be difficult and full runtime behavior is often required.

Build/architecture details mentioned from the Rust port

• The video references internal architecture changes:
  • Layering: many crates improve compile-time modularity but complicate cyclic dependencies
  • Zig patterns like tag pointers for interfaces
  • Trait costs are discussed (including debate about inlining/devirtualization)
  • The current Rust approach allegedly uses a macro approach for generating external declarations, relying on LTO/linker for optimization
• Potential compilation-time bottlenecks are highlighted as an ongoing expectation.

Sponsorship note (not central to technology)

• The sponsor is Work OS, referenced for auth/rate-limiting and MCP hosting (“MCP Night” event).
• It’s not tied directly to Bun, aside from its placement in the video.

Main speakers / sources

Primary speakers

• Video narrator/host: speaks throughout; discusses Jared, Claude Code, Open Code, and the rewrite analysis
• Jared: Bun project lead; quoted about Rust rewrite progress, tests, unsafe philosophy, and performance expectations
• Dax: from Open Code; publicly explains the move away from Bun
• Theo: appears during the sponsor segment

Referenced sources / articles

• William Johnson: article about Bun’s future
• Anthropic engineering postmortem: discussed regarding Claude Code issues