Bun has an open PR adding shared-memory threads to JavaScriptCore

Original Article ↗ Hacker News Discussion ↗

Context & Scope of the PR

  • PR adds shared-heap threads to Bun’s fork of JavaScriptCore, based on a previously published “Concurrent JavaScript” design.
  • It is not against upstream WebKit, but Bun’s own heavily modified fork.
  • Author confirms the PR description is entirely LLM-generated and the change is more complex than Bun’s recent Rust rewrite.

Shared-Memory Threads vs Existing JS Concurrency

  • Several commenters note JS already has concurrency via workers, SharedArrayBuffer, and Atomics.
  • Key distinction: today shared memory is opt‑in and data‑only; the PR makes the whole object heap shared by default.
  • Supporters argue this enables “true” multithreading and more ergonomic high‑performance patterns; critics say it normalizes mutex-based shared memory, a historically bug-prone model.

Correctness, GC, and Performance Concerns

  • Strong worry about race conditions on prototype chains, property definition, and JS object graphs in general.
  • Some say this is unsafe “for the masses” and that JS’s single-threaded model was a protective constraint.
  • GC is a major concern: current version uses stop‑the‑world collection, which people say will hurt latency and defeats claims of “no single‑threaded slowdown.”
  • Historical note: earlier multi-threaded JS attempts in other engines were rolled back due to GC and interop complexity.

LLMs, Giant Diffs, and Reviewability

  • The PR is ~270k lines across ~1,800 files; many see this as effectively unreviewable.
  • People criticize the LLM-written PR description style (overly long, “honesty” branding, em‑dash heavy).
  • Skeptics argue LLMs are especially bad at concurrency, and LLM review of LLM code doesn’t inspire confidence.
  • Others counter that humans are also bad at threading, that extensive tests, TSAN, and stress tests help, and that LLMs enable ambitious prototypes that humans can later refine.

Trust in Bun and Production Use

  • Some praise Bun’s DX, “batteries-included” tooling, and speed; others report memory leaks, unstable behavior, and unresolved bugs.
  • Bun’s broader AI-driven development (Rust rewrite, AI bots handling issues/PRs) erodes trust for some; they plan or have prepared to migrate back to Node or consider Deno.
  • There is concern that large AI-generated changes plus limited human oversight make Bun unsuitable as a dependable runtime foundation.

Broader Reflections: Threads, Databases, and Language Choice

  • Debate over whether JS/TS is a good fit for high-performance, multithreaded systems like SQL databases.
  • Some argue TS + Bun + threads could support competitive DBs; others say JS’s performance tier and memory model make this unrealistic compared to C/C++/Rust.
  • Several reiterate a preference for message-passing, actors, or process-based models over shared-everything threading, citing maintainability and reliability.