La reescritura experimental de Bun en Rust alcanza 99.8% de compatibilidad de pruebas en Linux x64 glibc

• La reescritura en Rust de Bun supera el 99.8% del conjunto de pruebas existente en entornos Linux x64 glibc
• La base de código es “básicamente la misma base de código”, y al pasar a Rust el compilador puede hacer cumplir el ciclo de vida de los tipos y permitir usar destructores cuando se necesitan
• Las partes inseguras quedan más claras con unsafe en Rust, lo que tiene el efecto de impulsar la refactorización
• La razón de la reescritura fue que se cansaron de dedicar mucho tiempo a preocuparse y corregir fugas de memoria, crashes y problemas de estabilidad, y querían que el lenguaje ofreciera herramientas más sólidas para evitarlo
• La escala total se expresó como una reescritura de 960,000 LOC, y tras pasar el conjunto de pruebas en Linux, otras plataformas serán el siguiente objetivo

---

Estado de la reescritura en Rust

• La reescritura en Rust de Bun supera el 99.8% del conjunto de pruebas existente en entornos Linux x64 glibc
• La base de código es “básicamente la misma base de código”, y al cambiarla a Rust el compilador puede hacer cumplir el ciclo de vida de los tipos y permitir usar destructores en el momento necesario
• Las partes inseguras se vuelven más explícitas con unsafe en Rust, lo que también impulsa la refactorización
• Entre los motivos de la reescritura está que se cansaron de pasar mucho tiempo preocupándose y corrigiendo fugas de memoria, crashes y problemas de estabilidad, y querían que el lenguaje ofreciera herramientas más fuertes para prevenir este tipo de problemas
• La escala total se describió como una reescritura de 960,000 LOC, y el código ya funciona en la práctica, pasa el conjunto de pruebas en Linux y pronto apuntará también a otras plataformas

Próxima información a publicar y respuestas sobre la compilación

• El significado para Bun, los benchmarks, el uso de memoria, la mantenibilidad futura y el proceso real de la reescritura se tratarán en una entrada de blog aparte
• El proceso de reescritura no fue simplemente decir “claude, rewrite bun in rust. make no mistakes”, y el trabajo para llegar a un estado que funcionara de principio a fin comenzó hace 6 días
• Se menciona que, si hubiera sido totalmente manual, habría implicado una cantidad enorme de trabajo
• El tiempo de compilación es básicamente similar al de la versión actual en Zig, que usa un compilador Zig más rápido, y se afirma que si hubieran usado el compilador Zig upstream, el port a Rust habría compilado más rápido
• El rendimiento se tratará en una entrada de blog aparte
• Sobre el siguiente paso de reemplazar la propia libc por la versión en Rust frankenlibc, se dice que antes de eso harán su propia libc

[GN⁺]

Comentarios en Hacker News

• Ya había algo sobre esto hace 4 días: https://news.ycombinator.com/item?id=48019226
  Una persona que trabaja en Bun dijo que era su propia rama, que en ese momento el hilo era una sobrerreacción a código que no funcionaba, que aún no habían decidido hacer el rewrite y que había altas probabilidades de que todo el código terminara descartándose
  Dijo que quería ver cómo era una versión funcional, cómo quedaban el rendimiento y la mantenibilidad, y qué tan difícil era pasar la suite de tests de Bun para comparar lado a lado la versión en Rust y la versión en Zig

  • Cuando escribió ese mensaje, cargo check arrojaba más de 16,000 errores del compilador y ni siquiera podía mostrar el número de versión ni ejecutar JavaScript
    No esperaba que funcionara tan rápido, ni que el rendimiento fuera tan competitivo, y los detalles saldrán en una entrada de blog
  • Parece que ya probaron la mantenibilidad, el rendimiento y la verificación con la suite de tests, y luego tomaron una decisión
  • Si es así, significa que hasta ahora ha sido muy exitoso como experimento
  • Hace unos días también dijo: “el open source parece que va a ir en la dirección opuesta. Se prohibirán las contribuciones humanas. El slop será una reliquia nostálgica de 2025~2026”
    Debí haberlo esperado después de la adquisición por Anthropic, pero igual me decepciona. No me opongo a la tecnología de modelos de lenguaje a gran escala en sí, pero me repugna la forma en que estas empresas de “IA” han ganado poder al devorar la industria del software y la sociedad en general, creando dependencias muy poco sanas
    Hay que mirar varios movimientos hacia adelante y preparar stacks de software y comunidades sin slop. Eso incluye a Zig y su ecosistema. Aunque nosotros y las futuras generaciones no podamos vivir por completo sin slop, es más importante que nunca garantizar una cultura de computación sostenible con libertad como valor real

• Es muy impresionante que lo hayan logrado tan rápido. Yo llevo 5 meses en un proyecto parecido de portar TypeScript a Rust, y no tengo Mythos ni acceso ilimitado a tokens
  Aun así, ya estoy cerca de una tasa de aprobación de casi 100%, y al momento de escribir esto va en 99.6%: https://tsz.dev
  Rust es muy apto para escribir código con modelos de lenguaje a gran escala. Gracias a su sistema de tipos estricto, se evitan muchas tonterías que en otros lenguajes sí podrían pasar
  Pero escribir código con modelos de lenguaje a gran escala no elimina la necesidad de una visión de diseño ni del juicio para evaluar trade-offs al construir un proyecto. Por eso Jarred y su equipo son las personas adecuadas para aprovechar y usar enormes cantidades de código generado con modelos de lenguaje a gran escala

  • El hecho de que Rust fuerce invariantes en tiempo de compilación ayuda a que los modelos de lenguaje a gran escala reciban feedback rápido y puedan corregir rumbo, así que ayuda a generar código que funcione
    Por otro lado, Rust es un lenguaje complejo y pequeños cambios pueden obligar a hacer refactors en código muy distante, generando avalanchas de refactorización. Si la arquitectura inicial es mala o insuficiente, conforme el modelo vaya expandiendo gradualmente el codebase como suele hacerlo, el riesgo de que todo se vuelva espagueti es grande
    Me preocupa que al final termine siendo un programa que compila y corre, pero que ningún humano pueda leer o mantener
  • También estoy haciendo algo parecido con Postgres multihilo. En 1 mes ya pasó 96% de los tests de regresión de pg y llegó a 823K LOC
    Sin Mythos, eso fue todo lo que dieron 8 cuentas de Codex de $200 al mes
    También ahí vi las ventajas de Rust, y con base en mi experiencia con Postgres creo que se pueden tomar buenas decisiones de diseño en varias partes que durante mucho tiempo le han costado a la gente en pg. Me entusiasma que, gracias a la IA, mejorar software complejo de maneras que antes no eran prácticas se vuelva más posible
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Cuando Microsoft reescribió esto en Go, una de las personas líderes dijo que eligieron Go en vez de Rust por la similitud de paradigma. Comentó que el garbage collection y otras cosas eran parecidas, y que Rust habría sido más difícil y habría requerido más rodeos. Me da curiosidad cómo lo ves desde la experiencia directa
  • Rust es excelente, pero cuando intentas construir software en Rust con modelos de lenguaje a gran escala en proyectos grandes, la forma en que quieres trabajar se desmorona
    Incluso mantener o establecer límites limpios deja de ser un estado de concentración y se convierte en una revisión dolorosa, y al final uno cae en modo de postergación
  • Me costó hacer que Opus dejara de ignorar los idioms de Rust y dejara de escribir el Rust más raro posible. Me pregunto si tienes algún tip

• No tengo una base súper sólida, pero ya no quiero seguir vinculado con Bun. Es más bien una corazonada, pero no logro confiar ni apoyarlo
  Forkearon Zig para aprovechar rewrites con LLM, e hicieron cosas como compilación no determinista que el equipo de Zig claramente no quería
  Ahora parecen estar quejándose mientras hacen un rewrite con LLM en Rust. Puede que hayan llegado hasta aquí justamente porque la filosofía de diseño de Zig forzaba decisiones difíciles pero correctas, y existe la posibilidad real de que el rewrite en Rust sea el comienzo de la caída
  Es un juicio más político que técnico, pero Bun parece completamente sostenido por Claude. No me sorprendería que el siguiente mensaje de marketing de Anthropic fuera: “Claude Mythos reescribe en Rust un runtime JS líder de 950K LOC”

  • No sé si el llorón es el desarrollador que escribe código en su propio repositorio o la persona en Hacker News que se queja de eso
  • No vi a Jarred quejándose, creo que la emoción está mal dirigida
    El hilo de Twitter enlazado presenta fundamentos técnicos claros
  • No estoy tan metido personalmente en Bun, pero no entiendo por qué esto sería importante. Me pregunto si también revisan así las demás dependencias
    Trabajar en el ecosistema JS/NPM ya implica depender muchísimo de una fe pura en dependencias no verificadas, y no veo por qué eso cambiaría antes o después de un rewrite con LLM. Si cumple el objetivo original y el contrato de API, ¿cuál es la diferencia? Además, dudo que la gente estuviera leyendo con tanto cuidado el código fuente anterior
  • De acuerdo. Bun siempre tuvo una filosofía de diseño muy clara. Querían hacerlo todo: runtime, bundler, suite de tests, package manager, y además sacar parches que rompen cosas cada semana
    Siempre fue esa idea de aplastar a cada competidor existente siendo mejores, más rápidos y más fuertes, pero era demasiado obvio que jamás iban a seguir el Keep It Simple Stupid
    También estaba claro que, en el futuro cercano, solo lo veríamos en producción real en startups de YC que se irían incendiando una por una como si les hubieran echado acelerante. Ahora parece que ya pasaron el punto de no retorno
  • Bun está prácticamente muerto
    Anthropic compró Bun en un intento algo tonto de resolver sus propios problemas de “rendimiento”. Al parecer no se dieron cuenta de que el problema era que el código ya era bastante malo desde el principio
    Aun así, al menos trajeron desarrolladores realmente capaces, así que quizá eso ayudó un poco
    Pero en el proceso Bun dejó de parecer un proyecto público y se volvió algo más cercano a una herramienta interna de Anthropic, y ahora está bastante mal enfocado y sobreprotegido por dinero de IA
    Ojalá se pueda rescatar aunque sea parte del esfuerzo invertido en Bun cuando se desinfle la burbuja. No parece que Anthropic vaya a mantenerlo a largo plazo. No son una empresa que venda soporte de runtimes, ni tienen el tamaño de Google como para mantener un runtime de lado

• Dejando de lado por un momento la intervención de IA, me parece un buen cambio
  Bun tenía muchísimos crashes y bugs de memoria usando Zig, a diferencia de Deno que está basado en Rust
  Claro, si el port de Bun a Rust tiene mucho unsafe, no se va a resolver todo por arte de magia, pero igual debería mejorar

  • Me pregunto si hay estadísticas o fuentes que muestren que Bun tenía muchísimos crashes y bugs de memoria. No es que crea que sea falso
    El hecho de que las partes feas se vean más claramente con unsafe, empujando a refactorizarlas, hace pensar que no es solo un tema del lenguaje sino también algo que Bun en parte se causó a sí mismo
  • Me pregunto si la afirmación es que usar Zig hace que haya “muchísimos crashes y bugs de memoria”
    Si fuera así, ¿no significaría que es prácticamente imposible hacer software de alta calidad con esa herramienta? Se han hecho muchas cosas de buena calidad en C/C++, así que me pregunto qué estaría haciendo mal Zig
  • Como unsafe queda señalado con claridad, es más fácil de encontrar y se genera de forma natural una lista de problemas a resolver

• Esto tomó 6 días. Aunque al final no termine siendo un resultado importante, muestra cómo se están conectando ahora y en adelante los tokens y la cantidad de trabajo
  Será más difícil competir con personas o empresas que tengan más recursos de cómputo. Ellos simplemente podrán hacer cosas que yo no puedo

  • Traducir un proyecto de un lenguaje a otro cuando existe una buena suite de tests es uno de los casos clásicos en que los modelos de lenguaje a gran escala funcionan bien
    Si puedes usar el codebase terminado como ejemplo y validarlo con la suite de tests, es mucho más fácil iterar hacia el objetivo deseado. El modelo ya puede ver cuál es la meta y cómo se implementó una vez, así que es un problema mucho más sencillo que empezar desde una especificación
  • Lo mismo se podría haber dicho sobre la fuerza de vapor o la electricidad. Y no es solo una analogía superficial. La magia de estas cosas está en que son motores de información de propósito general
    Metes capital, las construyes con técnicas escalables bien entendidas, conectas la electricidad y sale valor
    El punto es que, igual que la electricidad no terminó convirtiéndose en eso en el mundo moderno, no necesariamente va a surgir una separación entre “los que tienen y los que no tienen”
  • No está claro. Los productos realmente buenos por lo general salen de hacer una o dos cosas extremadamente bien, no de hacer muchas
    Lo que se ve hasta ahora es más bien “wow, ¡ahora soy un ingeniero 10x!” soltando mucho más código, pero sin una dirección clara ni buen gusto. La mayor parte del trabajo actual basado en modelos de lenguaje a gran escala solo parece ruido
  • No. Cada vez es más fácil correr estos agentes en local
    No sé si ya probaste Qwen 3.6 27b, pero lo que puede hacer para su tamaño es una locura. Si manejas bien el contexto, en proyectos pequeños ya se puede hacer vibe coding al 100%
    Estos modelos también van a bajar por competencia de precios, igual que el cómputo
  • Me pregunto cuánto habría costado esto en dólares si se hubiera pagado con la tarifa estándar de Anthropic. ¿Alguien puede hacer aunque sea una estimación aproximada?

• Mucha gente está aceptando esto tal cual, pero gran parte fue posible gracias a una suite de tests extensa y exhaustiva, muy por encima del estándar, que ya se había construido antes

  • Aun así, es impresionante, porque incluso a un ingeniero muy capaz le habría tomado muchísimo más tiempo lograr algo así
    Cuando luego se haga marketing de esto, estaría bien que también dijeran cuánto esfuerzo humano hubo en diseñar y curar la suite de tests que hizo posible esta velocidad
    Las suites de tests funcionan casi como un entorno ideal para la generación actual de modelos de lenguaje a gran escala. Una suite de tests suficientemente completa se vuelve una especificación que el agente puede implementar de la manera que quiera, y aquí eso fue en Rust
    En proyectos con tests tan bien hechos como Bun, dependiendo del caso, hasta parecería posible tirar por completo el código fuente y dejar acceso solo a los tests para reimplementar todo desde cero
  • Si esa suite de tests “por encima del estándar” fuera lo que vuelve esta tarea singularmente posible frente a otros proyectos, me pregunto cómo se reconcilia eso con la afirmación de que Bun, a diferencia de otros programas en Zig, es especialmente inestable y por eso necesita un rewrite
    Si parte de la responsabilidad también recae en la suite de tests, me pregunto qué implicaría eso para el port a Rust
  • ¿Entonces se supone que solo hay que mirar que esto se puede hacer en 6 días?
    ¿Y hay que ignorar las cientos de miles de horas invertidas en la arquitectura original y en la suite de tests que lo hizo posible?

• Vale la pena verlo como un caso de advertencia sobre ports a Rust hechos con IA
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Pasar los tests no significa necesariamente que funcione
    El compilador C hecho con Claude code pasó el 100% de los tests de gcc, pero ni siquiera pudo ejecutar hello world
  • La lección que dejan esos casos es un poco distinta. Los modelos de lenguaje a gran escala construyen en función del loop de feedback que les das
    Si solo les das tests lógicos, no van a considerar para nada la velocidad. Si incluyes tests que midan velocidad y les pides alcanzar cierto rendimiento, también harán eso
    Es la misma clase de error que cometen en otros contextos. No tienen contexto de sentido común sobre las cosas que un humano considera importantes. Si no fuerzas los límites, los ignoran
  • Si te interesa, se discutió aquí: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - marzo de 2026, 422 comentarios

• Qué época tan increíble para estar vivo
  Las dinámicas fundamentales de la industria y de la profesión cambiaron en muy poco tiempo, prácticamente de la noche a la mañana
  Algunos días me emociona sentir que ahora hay demasiadas cosas que puedo hacer; casi cualquier cosa que quiera se puede construir de inmediato, y el 100% de lo que soñaba hacer con software puede volverse realidad
  Otros días me da miedo lo que va a pasar con el mercado laboral
  De repente se puede obtener muchísimo con muy poco, y la cantidad de software que el mundo necesita tiene un límite
  ¿Van a quebrar todas las empresas cuyo modelo principal de negocio es vender software?
  ¿Qué pasa si solo ciertas empresas o gobiernos tienen acceso a los mejores modelos?

  • Pensemos en un negocio de software como un sistema de ticketing
    ¿100 empresas con mil millones de tokens podrán crear un producto mejor que un vendor especializado con 100 mil millones de tokens?
    Vendors de software y SaaS como los de “generador de logos” sí están muertos, pero a menos que la próxima generación de modelos de lenguaje a gran escala venga con un sistema de ticketing incorporado, los vendors de ticketing deberían estar bien. Podría bajar la necesidad de personal, pero no es seguro
  • Cerca del estallido de las puntocom también se decía bastante que la industria del software estaba “demasiado saturada”, y se les decía a estudiantes y gente buscando empleo que no entraran
    La idea era que, comparado con la cantidad de gente entrando, no había tanto trabajo para repartir, y el colapso reforzó esa narrativa
    Pero incluso siendo estudiante en ese momento, era evidente que el alcance del software era prácticamente infinito. Casi cualquier trabajo cognitivo que hacemos a mano puede hacerse con software. Una vez intenté enumerar esas cosas y enseguida me di cuenta de que había muchísimo por hacer
    Además, entendí que cada nueva forma de hacer el trabajo también hace aparecer muchas más cosas que antes ni imaginábamos. Las posibilidades eran incontables, y estaba claro que la narrativa de la “saturación” venía de una falta de imaginación y de comprensión de lo que es el software
    Por eso sabía que este campo nunca se iba a saturar. Era imposible quedarse sin cosas que convertir en software
    Pero ahora se siente distinto. Vamos a seguir creando software nuevo, sí, pero ahora me pregunto si la velocidad de escribir software puede llegar a superar nuestra velocidad para imaginar trabajo nuevo por hacer
  • Las empresas y los gobiernos sí tendrán acceso a modelos mejores que el público. De hecho, Mythos ya es un ejemplo de eso
    El público al menos podrá ayudarse con modelos rezagados respecto a la frontera

• Como mínimo, es interesante ver que este tipo de intentos avance
  Lo primero que me pregunto es qué tan buena y qué tan completa es la suite de tests para empezar. No lo digo por desacreditar, pero incluso si saliera 100% en todas las plataformas, me pregunto cuánta confianza tendría el equipo de Bun para hacer la migración

• Después de lo de Ubuntu coreutils la semana pasada, la idea de un rewrite en Rust con 99.8% de compatibilidad en tests me dejó una impresión realmente mala
  Hice clic en el tuit enlazado y me recorrió un escalofrío; ahora cuando veo estas cosas siento exactamente lo contrario. Casi me dan ganas de salir corriendo