Bun tiene un PR abierto que añade hilos de memoria compartida a JavaScriptCore

Contexto y alcance del PR

• El PR añade hilos de montón compartido al fork de JavaScriptCore de Bun, basado en un diseño de “Concurrent JavaScript” publicado previamente.
• No es contra WebKit upstream, sino contra el propio fork fuertemente modificado de Bun.
• El autor confirma que la descripción del PR está generada بالكامل por LLM y que el cambio es más complejo que la reciente reescritura en Rust de Bun.

Hilos de memoria compartida frente a la concurrencia de JS existente

• Varios comentaristas señalan que JS ya tiene concurrencia mediante workers, SharedArrayBuffer y Atomics.
• La diferencia clave: hoy la memoria compartida es opcional y solo de datos; el PR hace que todo el montón de objetos sea compartido por defecto.
• Los partidarios argumentan que esto habilita un multihilo “real” y patrones de alto rendimiento más ergonómicos; los críticos dicen que normaliza la memoria compartida basada en mutex, un modelo históricamente propenso a errores.

Preocupaciones sobre corrección, GC y rendimiento

• Hay una fuerte preocupación por condiciones de carrera en las cadenas de prototipos, la definición de propiedades y, en general, los grafos de objetos JS.
• Algunos dicen que esto es inseguro “para las masas” y que el modelo monohilo de JS era una restricción protectora.
• El GC es una preocupación importante: la versión actual usa recolección stop-the-world, lo que la gente dice que perjudicará la latencia y desmiente las afirmaciones de “sin ralentización monohilo”.
• Nota histórica: intentos anteriores de JS multihilo en otros motores se deshicieron por el GC y la complejidad de interoperabilidad.

LLMs, diffs gigantes y revisabilidad

• El PR tiene ~270k líneas a lo largo de ~1.800 archivos; muchos consideran que esto es, en la práctica, imposible de revisar.
• La gente critica el estilo de la descripción del PR escrita por LLM (demasiado larga, con branding de “honestidad”, y muy cargada de em-dashes).
• Los escépticos sostienen que los LLM son especialmente malos para la concurrencia, y que revisar código de LLM con LLM no inspira confianza.
• Otros responden que los humanos también son malos en threading, que las pruebas extensas, TSAN y los stress tests ayudan, y que los LLM permiten prototipos ambiciosos que los humanos luego pueden refinar.

Confianza en Bun y uso en producción

• Algunos elogian la DX de Bun, su tooling “batteries-included” y su velocidad; otros informan de fugas de memoria, comportamiento inestable y bugs sin resolver.
• El desarrollo más amplio de Bun impulsado por IA (reescritura en Rust, bots de IA gestionando issues/PRs) erosiona la confianza de algunos; planean o ya se han preparado para volver a Node o considerar Deno.
• Existe la preocupación de que grandes cambios generados por IA, más una supervisión humana limitada, hagan que Bun no sea adecuado como base confiable de runtime.

Reflexiones más amplias: hilos, bases de datos y elección de lenguaje

• Se debate si JS/TS es una buena opción para sistemas multihilo de alto rendimiento como bases de datos SQL.
• Algunos argumentan que TS + Bun + threads podrían soportar bases de datos competitivas; otros dicen que el nivel de rendimiento y el modelo de memoria de JS lo hacen irrealista frente a C/C++/Rust.
• Varios reiteran una preferencia por modelos de paso de mensajes, actores o basados en procesos en lugar de threading de “todo compartido”, citando mantenibilidad y fiabilidad.