HN Debrief

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

  • Programming
  • Developer Tools
  • AI
  • Open Source
  • Infrastructure

The submission points to a pull request on Bun’s fork of JavaScriptCore, not upstream WebKit, that adds shared-memory threads to JavaScript so code can run on multiple threads in one heap and share normal objects directly. The author says it implements a 2017 JavaScriptCore design for concurrent JavaScript and calls it one of the scariest merges Bun has attempted, because once a JIT and garbage collector become thread-aware, every future engine change inherits that complexity. That core idea landed as plausible. People familiar with VM internals said shared-heap threading in JavaScript is technically possible and the old design already mapped out how to handle prototype chains, garbage collection, and memory safety at a conceptual level. What changed here is not whether the model can exist, but that LLMs now seem capable of producing a working prototype of something this invasive.

Treat this as a sign that LLMs can now prototype deep runtime changes, not as proof those changes are ready to bet production systems on. If you depend on Bun, watch its governance, review process, and release quality more closely than its benchmark charts.

Discussion mood

Mostly negative and distrustful. People were intrigued by the shared-heap threading design itself, but the dominant reaction was that Bun’s AI-heavy process, giant patches, and weak human-readable justification make a runtime this invasive feel unsafe to adopt or maintain.

Key insights

  1. 01

    This is a real design, not a random stunt

    The proposal is not inventing threading out of thin air. It is an implementation of a 2017 JavaScriptCore design for concurrent JavaScript, and people who know that work say the hard conceptual questions were already explored years ago. That changes the read from "LLM hallucinated a VM feature" to "LLM helped turn an existing research direction into code."

    Separate skepticism about Bun’s process from skepticism about the underlying idea. If you care about this space, read the original JavaScriptCore design before deciding whether shared-heap JavaScript is nonsense or a plausible future feature.

      Attribution:
    • Jarred #1
    • pizlonator #1
    • bakkoting #1
  2. 02

    Shared objects are the actual leap

    What exists today in JavaScript is parallelism over byte buffers, not over ordinary language objects. SharedArrayBuffer and Atomics let you build low-level shared memory systems, but they force you to serialize strings, invent layouts, and treat memory as raw bytes. This PR matters because it aims to make existing object graphs shareable across threads, which is a qualitatively different programming model and far more usable for normal application code.

    Do not treat this as a small ergonomic tweak on workers. If shared object heaps become viable, they would open workloads that are currently impractical in JavaScript without dropping into native code or rebuilding everything on top of typed buffers.

      Attribution:
    • jitl #1 #2
    • curtisblaine #1
  3. 03

    The GC tradeoff is where prototypes get real

    The most concrete technical red flag was not "threads are scary" in the abstract. It was that the current implementation appears to rely on synchronous stop-the-world garbage collection, which is a classic way to make a threading demo work while punting the hardest VM engineering. That means the single feature claim can be true while the production cost shows up later as latency spikes and painful GC work.

    When evaluating ambitious runtime features, look first at the garbage collector and pause model, not just benchmark screenshots. A prototype that wins on throughput but regresses tail latency can still be a non-starter for servers and interactive tools.

      Attribution:
    • quotemstr #1
  4. 04

    Runtime rewrites have better test oracles

    A few comments cut through the hand-waving around "tests passing" by pointing out that language runtimes are unusual. They can be validated against large external test suites like TC39 Test262, Node’s mostly JavaScript tests, Web Platform Tests, and Bun’s own JS and TS corpus. That does not make a rewrite safe, but it does make runtime rewrites less blind than ordinary app rewrites because the behavioral spec is exercised by code outside the implementation language.

    If you are judging a runtime rewrite, ask which independent test corpora it passes and how much of that corpus is language-level rather than rewritten implementation tests. That is a much stronger signal than generic claims about green CI.

      Attribution:
    • esprehn #1
    • Jarred #1
  5. 05

    LLMs may be best at proving feasibility fast

    The strongest optimistic read was not that this should merge as-is. It was that giant system ideas can now be prototyped cheaply enough to test whether they are even worth serious engineering. That lowers the cost of exploring old papers, abandoned designs, and risky runtime ideas that previously died before anyone could afford a proof of concept.

    Use LLMs to collapse the cost of exploration, then reset your quality bar before shipping. The payoff is in learning which ideas deserve human effort, not in skipping that effort.

      Attribution:
    • sothatsit #1
    • rzmmm #1
  6. 06

    Bot-heavy maintenance already erodes confidence

    Concrete anecdotes about Bun’s issue tracker did more damage than generic anti-AI complaints. People linked trivial docs bugs where bots opened and reviewed fixes, then the changes languished or were closed as stale without human follow-through. That made the trust problem operational rather than philosophical. Even easy maintenance looked under-owned.

    If you are considering core tooling, inspect the project’s issue and PR hygiene yourself. A flashy architecture story does not compensate for unattended bug reports and unclear human ownership.

      Attribution:
    • Retr0id #1
    • Delgan #1
    • tomjakubowski #1

Against the grain

  1. 01

    Humans are bad at threading too

    The cleanest pushback against the anti-AI pile-on was that concurrency bugs are not some domain where humans are reliably great. One commenter said LLMs were useful for adding clang thread-safety annotations, fixing what the tooling found, and reshaping code so those annotations became possible. That does not prove this PR is good, but it does undercut the idea that human authorship alone would make multithreaded code trustworthy.

    If you work on concurrent systems, try using LLMs around formalized checks like thread-safety annotations instead of trusting freeform generation. The gains may come from making existing tooling easier to apply, not from asking a model to reason perfectly about races.

      Attribution:
    • murderfs #1
  2. 02

    JavaScript already has enough concurrency primitives

    Some people rejected the premise that JavaScript is blocked on true threads. Between workers, SharedArrayBuffer, and Atomics, it is already possible to build parallel systems and shared-memory data structures. From that view, the missing piece is not capability but discipline, and direct shared heaps remove one of the few guardrails that keep concurrency explicit.

    Before betting on shared-heap threads, ask whether your workload actually needs them or whether workers plus shared buffers already cover it. Many teams may gain more from better library abstractions over today’s primitives than from exposing full shared-state threading.

      Attribution:
    • jitl #1
    • n_e #1
    • quotemstr #1
  3. 03

    Bun is still useful despite the drama

    Not everyone was ready to write Bun off. A few people said it remains a practical drop-in for workloads where its speed and developer experience matter, and that migrating away is manageable as long as you avoid deep Bun-specific features. That view treats the current moment as a governance warning, not proof the product is unusable.

    If you are on Bun today, audit how locked in you are instead of panic-migrating on vibes alone. Keep the abstraction boundary clean so you can switch runtimes if confidence drops further.

      Attribution:
    • tyre #1
    • peregrinus_13 #1
    • adamddev1 #1

In plain english

Atomics ↩
A JavaScript API for performing thread-safe operations on shared memory buffers.
GC ↩
Garbage collection, the runtime process that automatically reclaims memory that is no longer in use.
JavaScriptCore ↩
The JavaScript engine used by WebKit and Safari, often abbreviated as JSC.
JIT ↩
Just-in-time compilation, where a language runtime compiles code to native machine code while the program is running.
shared-heap ↩
A memory model where multiple threads can directly access the same in-memory objects instead of copying data between them.
SharedArrayBuffer ↩
A JavaScript feature that lets multiple threads or workers access the same raw binary buffer in memory.
stop-the-world ↩
A garbage collection approach that pauses all running program threads while memory cleanup happens.
tail latency ↩
The slow end of the latency distribution, often measured as p95 or p99 response time rather than the average.
TC39 ↩
The standards body that develops the JavaScript language specification.
Test262 ↩
The official JavaScript conformance test suite maintained by the TC39 standards process.
TypeScript ↩
A typed superset of JavaScript that adds static checking and compiles down to standard JavaScript.
VM ↩
Virtual machine, software that emulates a computer so you can run another operating system inside your current one.
Web Platform Tests ↩
A large shared test suite used by browser engines to verify web standards behavior.
WebKit ↩
The browser engine used by Safari and some other browsers to render web content.

Reference links

Core design and implementation

Testing and standards references

  • TC39 Test262
    Cited as the main implementation-independent JavaScript conformance suite
  • Node.js test suite
    Mentioned as another large mostly JavaScript corpus useful for validating runtime behavior
  • Web Platform Tests
    Referenced as a broad browser standards test suite also used by runtimes
  • Bun test directory
    Pointed to as Bun’s own large JavaScript and TypeScript test corpus

Concurrency examples and related proposals

  • Lockless allocator in JavaScript
    Used as an example that JavaScript already supports advanced shared-memory patterns via SharedArrayBuffer and Atomics
  • TC39 proposal: Structs
    Raised in the debate over whether lightweight shared-memory threads need fixed-layout data types to be practical

Bun process and adoption references

  • Bun unsafe audit
    Shared as evidence that analysis went into the Rust rewrite, though others argued the document itself looked AI-generated
  • Prisma on Bun Rust rewrite
    Cited as a positive case study of using Bun’s rewrite in practice
  • Bun issue #14144
    Pointed to as a concrete issue with major ramifications for using Bun
  • Bun issue #28030
    Example of a trivial docs bug entering a bot-heavy maintenance loop
  • Bun pull request #28031
    Linked as the bot swarm fix attempt for the docs bug that later stalled out