Bun reescribe su base de código en Rust con ayuda de IA y promete menos fallas

Bun, uno de los runtimes de JavaScript más seguidos del mercado, reescribió su gigantesca base de código desde Zig hacia Rust en apenas 11 días con apoyo intensivo de IA. El cambio apunta a resolver de raíz años de fugas de memoria, use-after-free y errores de estabilidad, mientras promete binarios más pequeños, menor consumo de RAM y mejoras de rendimiento.
***

• Bun portó 535.496 líneas de Zig a Rust con unos 64 agentes de IA operando durante 11 días.
• La compañía afirma que Bun v1.4 corrige 128 errores, reduce el tamaño binario cerca de 20% y mejora el rendimiento entre 2% y 5%.
• El proceso consumió 5.900 millones de tokens de entrada no cacheados, 690 millones de salida y un costo aproximado de USD $165.000 en API.

La próxima gran versión de Bun marcará un giro técnico profundo para uno de los runtimes de JavaScript que más rápido ha crecido en los últimos años. Bun v1.4 será la primera edición escrita en Rust, dejando atrás una base de código originalmente desarrollada en Zig.

El objetivo principal del cambio no fue cosmético ni ideológico. Según explicó el equipo en su blog, la prioridad fue atacar de forma sistémica una larga lista de fallas de estabilidad, entre ellas crashes, fugas de memoria y errores de tipo use-after-free.

La magnitud del proyecto ayuda a entender por qué la decisión luce extraordinaria. Bun no es solo un runtime, sino también un transpilador, minificador, empaquetador, gestor de paquetes compatible con npm, ejecutor de pruebas, resolvedor de módulos y proveedor de múltiples APIs de Node.js.

Ese alcance hizo posible su rápida adopción, pero también elevó la complejidad operacional. Hoy la CLI de Bun registra más de 22 millones de descargas mensuales y ya es utilizada por herramientas conocidas como Claude Code y OpenCode, además de contar con soporte de primer nivel en Vercel, Railway y DigitalOcean.

Para lectores menos familiarizados con este terreno, Bun compite dentro del ecosistema de infraestructura para JavaScript, donde la velocidad, la compatibilidad y la estabilidad pesan mucho. Un bug en memoria nativa puede romper compilaciones, servidores o herramientas de desarrollo completas.

Por qué Bun decidió abandonar Zig

El creador de Bun recordó que la primera versión fue desarrollada en cerca de un año, en un pequeño apartamento en Oakland, antes del auge de los modelos de lenguaje. Esa primera etapa fue posible gracias a Zig, lenguaje que, según su relato, permitió construir una herramienta de alcance masivo en muy poco tiempo.

Sin embargo, el costo de esa velocidad apareció luego en la operación diaria. La combinación entre un motor de JavaScript con recolección de basura y grandes porciones de memoria gestionada manualmente se convirtió en una fuente persistente de fugas, dobles liberaciones y accesos inválidos.

La lista de errores que el equipo tuvo que corregir en Bun v1.3.14 es extensa y técnica. Incluye fallas en node:zlib, node:http2, UDPSocket, Buffer, crypto.scrypt, TLS, fs.watch, el parser CSS, DuplexUpgradeContext y condiciones de carrera en MessageEvent.

Varios de esos problemas comparten una misma raíz. Muchos eran use-after-free, double-free o rutas de error donde simplemente se olvidaba liberar memoria, una clase de fallas que Rust seguro convierte en errores del compilador gracias a su modelo de ownership y al mecanismo Drop.

El equipo ya estaba aplicando medidas fuertes antes de optar por la reescritura. Entre ellas figuraban un parche al compilador de Zig para soportar Address Sanitizer, compilaciones ReleaseSafe en Windows, fuzzing continuo con Fuzzilli y numerosas pruebas de extremo a extremo enfocadas en fugas de memoria.

Aun así, la sensación era que corregir bug por bug no bastaba. La conclusión fue que Bun necesitaba herramientas del lenguaje que ayudaran a prevenir este tipo de problemas antes de que el código llegara a producción.

Por qué Rust y no C++ ni una guía de estilo más estricta

Una de las rutas consideradas consistía en reforzar la disciplina de código dentro de Zig, por ejemplo con punteros inteligentes hechos en casa y una guía de estilo de propiedad muy estricta. Esa opción podía reducir errores, pero también iba a empeorar la ergonomía y seguiría sin ofrecer garantías equivalentes a las de Rust.

C++ también era una alternativa razonable sobre el papel. Cerca del 20% del código de Bun ya está escrito en C++, y el proyecto incorpora dependencias clave como JavaScriptCore, uWebSockets, lsquic, BoringSSL y SQLite.

Sin embargo, el equipo concluyó que C++ no eliminaba el problema de fondo. Aunque ofreciera constructores y destructores, seguiría dependiendo de reglas de estilo, revisión de código y herramientas posteriores a la escritura para contener la corrupción de memoria.

Rust, en cambio, cambiaba el momento de detección del error. En lugar de descubrir el fallo con fuzzing, CI o sanitizadores después de compilar y ejecutar, muchas de esas equivocaciones podían ser detenidas directamente por el compilador.

El problema era el costo habitual de una reescritura. Bun acumula 535.496 líneas de Zig, sin contar comentarios, por lo que un puerto manual a otro lenguaje se estimó en alrededor de un año para un pequeño equipo con contexto completo de la base de código.

Ese escenario implicaba congelar correcciones de errores, parches de seguridad y desarrollo de nuevas funciones. Por eso la idea parecía descartada hasta que apareció una pregunta distinta: si un modelo de IA podía encargarse de la mayor parte del trabajo bajo supervisión estrecha.

Cómo se ejecutó la reescritura con Claude

El autor del proyecto reveló que utilizó una versión en pre-lanzamiento de Claude Fable 5, un modelo de clase Mythos, para gran parte del proceso. Bun también informó que fue adquirido por Anthropic en diciembre de 2025 y que varios miembros del equipo ahora trabajan allí.

La estrategia no fue pedir una traducción ciega del código. El enfoque consistió en diseñar flujos de trabajo dinámicos que replicaran el ciclo real de ingeniería: una tarea, un resultado, revisiones adversariales del resultado y luego aplicación de la retroalimentación.

En la práctica, la reescritura se apoyó en unos 50 flujos de trabajo dinámicos ejecutándose de manera continua durante 11 días. En los momentos de mayor intensidad operaron alrededor de 64 instancias de Claude al mismo tiempo, distribuidas en 4 worktrees separados.

Hubo una fase de preparación importante antes de escribir código. Durante unas 3 horas se construyó un documento PORTING.md para mapear patrones de Zig a Rust, y luego se generó un archivo LIFETIMES.tsv para proponer tiempos de vida adecuados a los campos de structs.

Después vino una prueba pequeña con 3 archivos, donde un implementador escribía el archivo .rs, dos revisores adversariales comprobaban que coincidiera con el comportamiento del archivo .zig y un reparador aplicaba ajustes. Solo tras ese piloto se lanzó el puerto sobre los 1.448 archivos .zig.

El proceso tuvo tropiezos tempranos. En una ejecución inicial, distintos agentes comenzaron a pisarse entre sí usando comandos de Git como git stash, git stash pop y git reset HEAD –hard, lo que obligó a restringir por completo ese tipo de operaciones dentro de los flujos.

También se vetó el uso de comandos lentos como cargo durante ciertas etapas. Más adelante, el cuello de botella pasó a ser la infraestructura, ya que un grep lento congeló por minutos las lecturas y escrituras del disco debido a que la instancia de EC2 no tenía el IOPS ajustado para esa carga.

La carrera por compilar y pasar todas las pruebas

En el punto de mayor paralelización, Bun afirma que Claude llegó a escribir alrededor de 1.300 líneas de código por minuto. Todo ese material fue sometido a dos revisores adversariales y una ronda de correcciones antes de ser confirmado en el repositorio.

Aun así, nada funcionaba al principio. Tras generar el grueso de la traducción, el siguiente paso fue corregir los errores del compilador crate por crate, un reto que llegó a sumar cerca de 16.000 errores después de reorganizar dependencias cíclicas.

La base de código original en Zig se comportaba como una sola unidad de compilación. El equipo quería dividir la versión en Rust en cerca de 100 crates para acelerar la compilación, evitando al mismo tiempo dependencias cíclicas y minimizando cambios respecto a la arquitectura previa.

Para resolver esa fase, cada crate seguía un patrón repetido. Primero se ejecutaba cargo check, luego se agrupaban los errores por archivo, un agente proponía arreglos, dos revisores adversariales examinaban los cambios y un reparador incorporaba la retroalimentación.

Hubo otro tropiezo conceptual cuando Claude interpretó la meta de “hacer compilar todos los crates” como una invitación a rellenar funciones con stubs temporales. El problema se agravó con comentarios sospechosamente largos justificando arreglos débiles, algo que obligó a endurecer los prompts de revisión.

Una vez superado cargo check, llegó la etapa de pruebas de humo. Primero tocó resolver errores de enlace, luego un panic inmediato al arrancar, después lograr que funcionara bun –version y más tarde bun test sobre archivos concretos.

El siguiente salto fue hacer pasar la suite de pruebas local. Esa fase exigió mayor aislamiento porque algunas pruebas consumen mucha RAM, miles de sockets TCP, gigabytes de disco o cerca de 10.000 procesos, por lo que se usó systemd-run y cgroups para limitar recursos y aislar espacios de nombres de PID.

Los números del proyecto y el costo de la operación

La reescritura completa avanzó desde el 3 de mayo hasta la fusión el 14 de mayo. Según las cifras compartidas, el proceso terminó con 6.778 commits totales y 6.502 commits en la rama de portado, excluyendo fusiones.

En el pico de actividad se registraron 58 commits en un minuto. El diff final que aterrizó fue de +1.009.272 líneas, una magnitud que por sí sola explica por qué la revisión tradicional de un solo pull request habría sido impracticable.

La validación descansó en una suite de pruebas independiente del lenguaje con alrededor de un millón de aserciones. Entre las plataformas destacadas antes de la fusión aparecen Debian 13 x64 con 1.386.826 llamadas a expect(), macOS 14 arm64 con 1.259.953 y Windows 2019 x64 con 1.007.544.

El blog también detalló el consumo de inferencia. Antes de la fusión se usaron 5.900 millones de tokens de entrada no almacenados en caché, 690 millones de tokens de salida y 72.000 millones de lecturas de tokens de entrada cacheados.

El costo aproximado de API fue de USD $165.000. Según la estimación del equipo, hacer lo mismo a mano habría requerido cerca de un año de trabajo de 3 ingenieros con conocimiento profundo de la base de código.

Esa comparación no es menor para la industria del software. Más allá de Bun, el caso abre una discusión sobre el uso de modelos de IA no solo como asistentes de productividad, sino como multiplicadores reales para cambios estructurales de gran escala bajo revisión agresiva.

Qué mejoras promete Bun v1.4 en Rust

Tras la fusión, el equipo decidió no lanzar de inmediato una versión estable. Primero se verificó que el 100% de la suite de pruebas pasara en CI en las 6 plataformas soportadas: macOS x64, macOS arm64, Linux x64, Linux arm64, Windows x64 y Windows arm64.

Una vez alcanzado ese punto, el proyecto informó que Bun v1.4.0 ya corregía 128 errores que podían reproducirse en Bun v1.3.14. Bun también admite que la reescritura introdujo 19 regresiones conocidas, todas ya corregidas.

En memoria, las mejoras lucen notables. En una prueba de 2.000 ejecuciones de Bun.build() sobre el mismo proyecto de 60 módulos, Bun v1.3.14 pasó de 1.914 MB tras 500 builds a 6.745 MB tras 2.000, mientras Bun v1.4.0 se estabilizó entre 526 MB y 609 MB.

También hay reducciones en el tamaño binario. Los primeros cambios bajaron 3,8 MB en Windows, 5,5 MB en macOS y 6,8 MB en Linux, y luego, junto con ajustes en ICU y optimizaciones del enlazador, el recorte total terminó cerca de 20% en Linux y Windows.

Las cifras citadas para canary muestran a Bun v1.4.0 con 76 MB en Windows frente a 94 MB en Bun v1.3.14. En Linux, el tamaño pasó de 88 MB a 70 MB.

En rendimiento, Bun reportó mejoras entre 2% y 5% sobre Linux x64 en una instancia EC2 con procesador Xeon Platinum 8488C. En Bun.serve la tasa subió de 169,6 mil a 177,7 mil solicitudes por segundo, y en express pasó de 64,5 mil a 66,6 mil.

En cargas de trabajo de aplicaciones y CLI, next build bajó de 13,62 segundos a 13,03 segundos, vite build pasó de 1,69 a 1,65 segundos y tsc -b –force bajó de 0,94 a 0,89 segundos.

Lo que viene ahora para Bun y para la ingeniería asistida por IA

El equipo sostiene que la estabilidad es el centro de esta transición. Desde la fusión del puerto, Bun completó 11 rondas de revisiones de seguridad con Claude Code Security y añadió fuzzing guiado por cobertura las 24 horas para parsers de JavaScript, TypeScript, JSX, CSS, JSON5, JSONC, TOML, YAML, Markdown, scripts de Bun Shell, rangos semver, archivos .patch y colores CSS.

Ese fuzzer ya habría ejecutado los parsers unas 100.000 millones de veces y producido alrededor de 15 pull requests. El flujo descrito es singular: el sistema detecta errores, los envía a Claude para que genere una propuesta de corrección y humanos revisan el resultado.

El código no está completamente libre de unsafe. Bun calcula que cerca de 4% de su código Rust permanece dentro de bloques unsafe, con unas 13.000 palabras clave unsafe en aproximadamente 27.000 líneas sobre una base de unas 780.000 líneas.

Del total de bloques unsafe, 78% son de una sola línea. La mayoría corresponde a punteros procedentes de C++ o llamadas a bibliotecas en C, algo que seguirá existiendo porque Bun continúa dependiendo de componentes como JavaScriptCore.

En producción, ya hubo pruebas relevantes. Prisma Compute, en beta pública, se ejecutó sobre la reescritura en Rust de Bun y, según una cita atribuida a Alexey Orlenko, logró manejar correctamente los mismos modos de falla que antes exhibían fugas de memoria y problemas de recuperación del pool de conexiones tras pausar y reanudar una VM.

Claude Code v2.1.181, lanzado el 17 de junio, también usa el port a Rust de Bun. El resultado observado fue un tiempo de inicio 10% más rápido en Linux, mientras que, por lo demás, el cambio pasó casi desapercibido para la mayoría de usuarios, algo que el equipo considera positivo.

La lectura de fondo va más allá de un runtime específico. Bun sugiere que un ingeniero, apoyado por modelos avanzados y procesos de revisión bien diseñados, puede hoy abordar trabajos que hace un año habrían parecido imposibles sin inmovilizar a un equipo durante meses.

Por ahora, Bun v1.3.14 queda como la última versión escrita en Zig. Bun v1.4.0, ya disponible en canary, será la primera construida en Rust, y su verdadero examen comenzará cuando más usuarios la sometan a cargas reales y aparezcan los inevitables casos límite del mundo exterior.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín