Se hizo merge del PR de reescritura de Bun en Rust

• El PR #30412 introduce cambios para reescribir Bun en Rust y fue mergeado de la rama claude/phase-a-port a main el 14 de mayo de 2026
• La magnitud del cambio se muestra como 6,755 commits, 2,188 archivos y +1,009,257/-4,024 líneas
• Jarred-Sumner señaló que pronto saldrá una publicación de blog con más detalles
• Se explica que este cambio pasa la suite de pruebas existente de Bun en todas las plataformas y que corrigió varias fugas de memoria y pruebas inestables
• Se indica que el tamaño del binario se redujo entre 3 MB y 8 MB, y que los benchmarks se mantienen neutrales o muestran mejoras de velocidad
• Como razón más importante, se menciona que ahora podrán detectar y prevenir con herramientas asistidas por el compilador los errores de memoria en los que el equipo ha invertido durante años mucho tiempo de desarrollo y depuración
• Se explica que la base de código en general sigue siendo la misma y que también se mantuvieron la arquitectura y las estructuras de datos
• También se aclara que Bun sigue usando pocas bibliotecas de terceros y que no utiliza async Rust
• Los usuarios pueden probar este cambio con bun upgrade --canary
• Jarred-Sumner pidió que reporten issues si surge algún problema y comentó que podría bloquear el hilo si se calienta demasiado
• Antes de que llegue a la versión no canary, todavía quedan trabajos de optimización por hacer
• También quedan tareas de limpieza, que avanzarán en una serie de PR posteriores

[xguru]

Vaya, se fusionó un PR de un millón de líneas. Pasaron de Zig a Rust de una sola vez. Decían "no sé si esto se va a fusionar o no~~", y una semana después cambiaron de golpe el lenguaje de un código que ya funcionaba bien, jaja. Siento que está pasando algo histórico por culpa de la programación asistida por IA.

[heycalmdown]

¿En serio? Decían que solo estaban haciendo pruebas y que probablemente no lo iban a usar.

[freedomzero]

Como no lo hicieron en Zig, se pasaron de una a Rust con una audacia tremenda jaja

[GN⁺]

Comentarios de Hacker News

• Si en el anuncio dicen que la reescritura tomó una semana, dan ganas de preguntarse cuánto tiempo tomó preparar este archivo de instrucciones tan detallado para mapear modismos de Zig a modismos de Rust: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  Además, viendo las secciones Pointers & ownership y Collections, parece que el codebase de Bun ya usaba tipos internos de smart pointers para quedar listo para un mapeo 1:1 con sus equivalentes en Rust, y el crate de Rust bun_collections también ya existía
  Esta reescritura parece haber estado preparándose desde hace mucho tiempo y ser algo que el equipo de Bun propuso durante las negociaciones de adquisición con Anthropic

  • Cuando leo cosas sobre LLM, nunca sé qué es cierto, y con estos comentarios de Hacker News pasa lo mismo
    Hay demasiado dinero en juego, así que claramente existe el incentivo de infiltrar marketing disfrazado en la comunidad, y parte de esto también es simple lógica de bandos
    Ahora que Anthropic es dueño de Bun, también tiene bastantes incentivos para hacer que este trabajo parezca más fácil de lo que realmente fue
  • Dejando de lado factores como si el código Rust resultante es bueno, si el número de líneas es razonable o qué tan preparado estaba el codebase para esto desde el principio, un documento de 622 líneas sigue pareciendo un costo relativamente pequeño como artefacto previo para mejorar la consistencia o calidad de una salida de alrededor de 1 millón de líneas
    La escala de la salida es tan grande que aquí parece haber un efecto multiplicador
    Aun así, me da curiosidad cuánta experiencia tácita hizo falta para crear estas reglas y cuánto se iteró sobre ese archivo
    Por ejemplo, me gustaría saber cuántas de esas reglas surgieron de casos fallidos encontrados durante iteraciones de traducción
  • Dijiste using internal smart pointer types that map 1-to-1 to Rust equivalents, pero los smart pointers no los inventó Rust
    Si programas en cualquier otro lenguaje con punteros, ya estás modelando esos mismos tipos en tu cabeza
    Y también es falso que el crate de Rust bun_collections ya existiera
    Es solo parte del PR del codebase, no algo que ya existiera desde antes
  • Esto es igual que la demo de gcc de Anthropic
    Sería muy fácil reducir las dudas y a la vez empujar más la narrativa del IPO: publiquen en un repositorio aparte el trabajo oculto que hizo falta para impulsar la IA y dejen que todos reproduzcan los resultados
    Al final, lo que los clientes quieren conseguir también son 1 millón de líneas de código utilizables en “7 días”, ¿no?
    Todo el mundo podría intentar reproducirlo en su propio workflow y eso además subiría las métricas de uso de Anthropic
    Si de verdad fuera un resultado tan impresionante, me imaginaría primero un post en el blog con enlaces e instrucciones
    Claro, también puede ser que justo en este momento estén escribiendo ese post y se demuestre que yo estaba equivocado
  • Parece que la versión Zig de Bun tenía 3 tipos de punteros que mapeaban limpiamente a tipos de punteros ya existentes en Rust, y que para los otros 7 u 8 hubo que crear tipos nuevos
    ¿Ese es el centro de la teoría conspirativa?
    bun_collections tampoco parece ser mucho más antiguo que la guía de portabilidad

• [phone]: eso significa que Bun ahora supera 1 millón de líneas de código Rust
  Ya se está acercando al tamaño del propio compilador de Rust
  Aunque BunJS es en gran medida un wrapper de un intérprete de JavaScript y una reimplementación de librerías de NodeJS, o sea, se parece bastante a un wrapper de la biblioteca estándar de Rust
  BunJS parece estar convirtiéndose en un canario sobre la gestión de complejidad del software en la era de los LLM

  • mostly a JavaScript interpreter wrapper no es preciso
    Bun es un transpiler (parser) de JavaScript y CSS con baterías incluidas, minificador, bundler, gestor de paquetes tipo npm, runner de tests tipo Jest, y también trae APIs de runtime como clientes integrados de Postgres, MySQL y Redis
    Naturalmente, eso hace que el código crezca muchísimo
  • Bun no es un intérprete de JavaScript, sino más bien una reimplementación de las librerías de NodeJS y varias otras librerías
    Bun usa JavaScriptCore como motor JS, así que Bun en sí no hace, o al menos no debería hacer, parsing, interpretación ni JIT de JavaScript
    Corrección: leí mal. Decía “JavaScript interpreter wrapper”, así que la expresión sí es correcta
  • No sé si iOS lo detecta como número de teléfono por el + inicial o si también hay otro factor, pero en móvil aparece subrayado el cambio en número de líneas y si lo tocas puedes llamar por teléfono
    Si es por el tamaño del diff, está bastante gracioso
  • El codebase de Bun ya tenía una cantidad similar de líneas de código antes de la reescritura
    No tendría nada de raro que la reescritura diera como resultado un LOC parecido
  • Que un wrapper de JavaScriptCore tenga 1 millón de líneas es un gran ejemplo de lo que los agentes pueden llegar a hacer

• El resultado de $ rg 'unsafe [{]' src/ | wc -l es 10428, y el de $ rg 'unsafe [{]' src/ -l | wc -l es 736
  Por lenguaje: Rust 1443 archivos y 929213 líneas, Zig 1298 archivos y 711112 líneas, TypeScript 2604 archivos y 654684 líneas, JavaScript 4370 archivos y 364928 líneas, C 111 archivos y 305123 líneas, C++ 586 archivos y 262475 líneas, y C Header 779 archivos y 100979 líneas

  • Está bueno que en Rust se pueda buscar así el código potencialmente inseguro
    ¿Cómo buscas código inseguro en Zig?
    ¿O simplemente hay que asumir que está en todas partes?
  • Si la mitad de los archivos tienen la palabra clave unsafe, no parece una buena reescritura
    Si casi la mitad del código sigue siendo unsafe, ¿cuál es el sentido de reescribirlo en Rust?
  • Ojalá que Mythos sea de verdad lo mejor del mundo como ellos aseguran. Ahora sí lo van a necesitar
  • ¡En casa sí tenemos seguridad de memoria!
    Lo que hay en casa: 10428

• Todavía estamos escribiendo el post del blog sobre esto y vamos a compartir más detalles
  Si te interesa el contexto, revisa la lista de correcciones de bugs en las notas de lanzamiento de Bun v1.3.14 y versiones anteriores
  Rust no va a arreglar todo esto. Las fugas causadas por mantener referencias demasiado tiempo y todos los problemas de reentrada al cruzar el límite de JS siguen siendo responsabilidad nuestra
  Pero una parte importante de esa lista sí son use-after-free, double-free y olvidos de liberar en rutas de error, y esas cosas pasan a ser errores de compilación o limpieza automática

  • Hace 9 días dijiste esto[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    ¿Quizá no era una sobrerreacción después de todo?
    [0]: https://news.ycombinator.com/item?id=48019226
  • Tengo ganas de leer ese post del blog
    Me pregunto si planean correr los binarios de Zig y Rust en paralelo sobre una gran variedad de aplicaciones reales, o incluso hacer shadow execution en producción si es posible, para filtrar bugs
  • Si fuera un cliente de pago, me preguntaría cuánto costó este trabajo
    ¿Podrías dar una estimación aproximada?
  • Me pregunto si implementaron o planean implementar algún tipo de fuzz testing end-to-end comparando ambos binarios
    También me gustaría saber cuál es el plan concreto para lanzar esto sin romper los workflows de los usuarios
  • ¿Esto tiene posibilidades de arreglar los problemas de estabilidad de la API de Bun Workers? https://bun.com/docs/runtime/workers

• Hace unos 9 días, Jarred escribió que para nada era seguro que esto se fuera a fusionar y que todo era una sobrerreacción
  Qué irónico

  • Parece un caso ejemplar de liderazgo open source
    Imagínense el escándalo si Linus dijera que no va a reescribir el kernel de Linux y un día se levantara para fusionar una reescritura completa en Rust asistida por máquina
  • Cuando ya no eres dueño de la empresa, lo que digas se puede ignorar tranquilamente
    Era obvio que había que justificar el costo de tokens gastado
  • Pero eso no significa que la posibilidad de que se fusionara estuviera descartada

• Wow, va a estar entretenido ver qué pasa de aquí en adelante
  No hay forma de que este código haya sido revisado, pero tal vez ya entramos en una era posthumana donde se puede confiar en que los modelos escriban y revisen código
  Esto es como Gastown, pero ocurriendo en un proyecto mucho más famoso
  Me intriga cómo este proyecto va a poder agregar nuevas funciones en el futuro, o si siquiera va a ser posible
  ¿Alguien sabe exactamente cómo usa Anthropic a Bun?
  ¿Es parte de Claude Code?
  Me preocupa bastante seguir usando Bun en adelante, aunque no sé hasta qué punto esa preocupación también aplica al uso de Claude

  • Que se pueda confiar en que los modelos escriban y revisen código es absolutamente falso
  • Pasó todos los tests
    Si no puedes confiar en el test suite para detectar una traducción automática entre lenguajes, entonces en realidad no deberías confiar en ese test suite en absoluto :)
  • No sé cómo usa Anthropic a Bun, pero parece que lo están usando para mover la ventana de discusión hacia la idea de que está bien fusionar millones de líneas sin más
  • ¿En qué estado está el test suite?

• La verdad sí me entusiasma experimentar con traducción automática, pero me preocupa que haya muchos problemas de compatibilidad hacia atrás
  Empecé a mirar el commit y básicamente están resolviendo problemas de “los tests no pasan” cambiando los propios tests
  El trabajo real para que esto funcione correctamente con programas ya desplegados apenas está empezando
  Lo bueno, supongo, es que la comunidad de JS del lado del servidor por alguna razón ya está acostumbrada a que las cosas se rompan seguido

  • Me incomoda la idea de que entre al runtime que uso código que no fue revisado por ni una sola persona
    Pero si esto realmente funciona en la práctica sin mayores problemas, sería algo bastante impresionante
  • No sé si estas decisiones las tomó el LLM, pero siempre he sentido que Claude tiene más tendencia a hacer cosas sospechosas, como modificar tests, en vez de encontrar la solución correcta al problema
    GPT/Codex es más honesto en ese aspecto
  • No parece que esto vaya a salir como release estable de inmediato, pero felizmente acepto que me demuestren que estoy equivocado
    Soy escéptico con toda esta reescritura, y Jarred Sumner tiene tantísimos seguidores en internet que todo esto se siente como publicidad
  • Un ejemplo de resolver un problema de “los tests no pasan” cambiando el propio test: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    ¡Excelente! Solo agrégale un sleep(1) arbitrario al test. ¡No te preocupes, todo va a salir bien!
  • Quisiera revisar los tests para ver si hubo cambios realmente importantes, pero GitHub ni siquiera logra cargar el diff

• Los pocos proyectos míos que usan Bun los voy a migrar a otra cosa
  No confío en una gobernanza que permita un cambio tan temerario

  • Deno es excelente, pero siento que no recibe el cariño que merece
    Desde el principio estuvo bien hecho, así que ni siquiera necesita una reescritura
  • Yo simplemente voy a seguir con node
    Por otro lado, sí va a ser interesante ver cómo resulta este bautismo de fuego, y a largo plazo sospecho que al final terminarán arreglando los problemas

• Hay un hilo que vale la pena ver por motivos educativos. Hace una semana, Jarred volvió a apartarse de la decisión de fusionarlo, y una multitud de soldados de infantería atacaba a quienes predecían que pronto se iba a fusionar:
  https://news.ycombinator.com/item?id=48073680
  Viéndolo ahora, no envejeció muy bien, ¿verdad?

  • Pasar de “Todo este hilo es una sobrerreacción. 302 comentarios sobre código que no funciona. No nos hemos comprometido a hacer la reescritura. Hay una probabilidad muy alta de que todo este código termine tirado a la basura” a una fusión total en 10 días, incluso contando lo que parecía simple curiosidad experimental, se ve realmente demente
  • Siempre me sorprende ver cuántos seguidores del poder hay en el mundo a los que no les importa mucho qué bota están lamiendo

• Si esto sale aunque sea un poco mal, las burlas de que es un narco consumidor de su propia mercancía van a ser interminables y deprimentes

  • Hay demasiada gente emocionalmente poco preparada para la posibilidad de que no salga ni un poco mal
  • ¿No bastaba ya con el código filtrado de Claude Code para convertirlos en objeto de burla?
  • Ya están consumiendo su propia mercancía
    ¿Leíste el paper de Mythos? La antropomorfización es realmente fuerte
    Puede que solo sea una forma barata de llamar la atención, pero si de verdad creen que los LLM son conscientes... wow