Bun tem uma PR aberta adicionando threads de memória compartilhada ao JavaScriptCore

Contexto e Escopo da PR

• A PR adiciona threads com heap compartilhado ao fork do JavaScriptCore do Bun, com base em um design de “Concurrent JavaScript” publicado anteriormente.
• Ela não é contra o WebKit upstream, mas sim contra o fork fortemente modificado do próprio Bun.
• O autor confirma que a descrição da PR foi inteiramente gerada por LLM e que a mudança é mais complexa do que a recente reescrita em Rust do Bun.

Threads de Memória Compartilhada vs. Concorrência JS Existente

• Vários comentaristas observam que o JS já tem concorrência via workers, SharedArrayBuffer e Atomics.
• A distinção principal: hoje a memória compartilhada é opcional e apenas para dados; a PR torna todo o heap de objetos compartilhado por padrão.
• Defensores argumentam que isso permite “verdadeira” multithreading e padrões de alto desempenho mais ergonômicos; críticos dizem que isso normaliza memória compartilhada baseada em mutex, um modelo historicamente propenso a bugs.

Preocupações com Correção, GC e Desempenho

• Há forte preocupação com condições de corrida em cadeias de protótipos, definição de propriedades e grafos de objetos JS em geral.
• Alguns dizem que isso é inseguro “para as massas” e que o modelo single-threaded do JS era uma restrição protetora.
• O GC é uma grande preocupação: a versão atual usa coleta stop-the-world, o que as pessoas dizem que vai prejudicar a latência e contradiz as alegações de “sem lentidão single-threaded”.
• Nota histórica: tentativas anteriores de JS multithread em outros motores foram revertidas por causa do GC e da complexidade de interoperabilidade.

LLMs, Diffs Gigantes e Revisabilidade

• A PR tem cerca de 270 mil linhas em aproximadamente 1.800 arquivos; muitos consideram isso, na prática, impossível de revisar.
• As pessoas criticam o estilo da descrição da PR escrita por LLM (excessivamente longa, branding de “honesty”, abundância de travessões longos).
• Céticos argumentam que LLMs são especialmente ruins com concorrência, e revisar código de LLM com LLM não inspira confiança.
• Outros respondem que humanos também são ruins com threading, que testes extensivos, TSAN e testes de estresse ajudam, e que LLMs permitem protótipos ambiciosos que humanos podem refinar depois.

Confiança no Bun e Uso em Produção

• Alguns elogiam a DX do Bun, as ferramentas “batteries-included” e a velocidade; outros relatam vazamentos de memória, comportamento instável e bugs não resolvidos.
• O desenvolvimento mais amplo do Bun com IA (reescrita em Rust, bots de IA lidando com issues/PRs) erode a confiança de alguns; eles planejam ou já se prepararam para voltar ao Node ou considerar o Deno.
• Há preocupação de que grandes mudanças geradas por IA, somadas à supervisão humana limitada, tornem o Bun inadequado como base confiável de runtime.

Reflexões Mais Amplas: Threads, Bancos de Dados e Escolha de Linguagem

• Debate sobre se JS/TS é uma boa opção para sistemas multithread de alto desempenho, como bancos de dados SQL.
• Alguns argumentam que TS + Bun + threads poderiam suportar bancos de dados competitivos; outros dizem que a camada de desempenho e o modelo de memória do JS tornam isso irrealista em comparação com C/C++/Rust.
• Vários reiteram a preferência por modelos de passagem de mensagens, atores ou baseados em processos em vez de threading com tudo compartilhado, citando manutenibilidade e confiabilidade.