Bun 1.4 Rust rewrite is not looking good?

Original Article ↗ Hacker News Discussion ↗

Concerns are mounting over Bun’s Rust-based 1.4 rewrite and its heavy reliance on AI-assisted coding, as repeated missed release targets and a stalled stable-release cadence have shaken confidence among some early adopters. Supporters counter that the canary builds are already in production at companies like Anthropic and Prisma, argue that large-scale rewrites are naturally bumpy, and see this as a promising proof-of-concept for LLM-driven development. The debate touches not only on Bun’s stability and roadmap versus alternatives like Node and Deno, but also on whether AI-generated code can reliably underpin critical infrastructure.

Overall sentiment on Bun 1.4 and the Rust rewrite

  • Some users say Bun has been “amazing” in practice (fast, integrated tooling, nicer DX) and are optimistic about the Rust rewrite improving safety and leaks.
  • Others report constant instability: random build failures, memory leaks, and regressions that erased any resource savings, making them regret adopting Bun for “serious” projects.
  • A few are using 1.4 canary (Rust rewrite) in production and report it basically works, with minor issues (e.g., REPL rendering glitches).

Release cadence, “not shipping,” and communication

  • A central concern: Bun’s previously frequent releases stalled for ~3 months during the Rust rewrite, after a history of 2–3 week cadence.
  • Critics argue repeated, optimistic “it ships tomorrow” style public statements, followed by delays, undermine confidence and suggest trouble with the rewrite.
  • Defenders say a big rewrite naturally pauses releases; caution and polishing before a major cut is reasonable.
  • There is frustration that canary builds are in heavy real-world use (e.g., by large users) but no official stable release appeared for a long time, blocking adoption in conservative environments.
  • Near the end of the thread, people note that 1.4 has in fact been released.

Code quality, dead code, and metrics

  • One line of attack cites large volumes of open PRs and claims of dead code as evidence the rewrite “is not looking good.”
  • Others call this a weak or misleading argument:
    • 5k+ open PRs are said not to prove decline in quality.
    • The “11k lines of dead code” example is corrected: that removal applied to the older Zig codebase, not the Rust port.
    • Some argue <1% dead code in a million-line project would be acceptable; others say dead code should be zero and linters exist.

Node, Deno, and alternatives

  • Some ask why an alternative to Node is needed at all; they cite Node’s growing standard library, test runner, TS support, and env-file support.
  • Bun advocates highlight integrated tooling (package manager, test runner, bundler, image and SQL support) and performance as major advantages over Node’s toolchain sprawl.
  • Others suggest just using pnpm/yarn on Node, or Deno, for more stability and standards alignment.

AI-generated code and broader AI debate

  • The rewrite is seen as a key test case for LLM-assisted development:
    • Supporters say language-to-language rewrites are a natural fit for LLMs, especially when validated by tests.
    • Skeptics question long-term maintainability, potential “spaghetti” code, and total economic cost once human oversight and token spend are counted.
  • Some explicitly hope the rewrite fails to puncture hype that “AI will replace developers”; others argue people are bending over backward either to prove or disprove LLM success.