Bun anunció el 8 de julio de 2026 que reescribió por completo su runtime de JavaScript y TypeScript, pasando de Zig a Rust. El anuncio, publicado en el blog oficial del proyecto bajo el título «Rewriting Bun in Rust», generó una discusión de más de 590 puntos en Hacker News y se transformó en uno de los movimientos técnicos más comentados de la semana en la comunidad de runtimes JS.
Según la compañía, el objetivo central del cambio es eliminar de raíz una clase de errores de memoria que venía afectando la estabilidad del proyecto desde sus orígenes en Zig.
Qué es Bun y por qué se reescribe en Rust
Bun es un runtime todo-en-uno para JavaScript y TypeScript que compite con Node.js y Deno, con foco en velocidad de arranque, un bundler y un gestor de paquetes integrados.
Desde su lanzamiento estuvo escrito en Zig, un lenguaje de sistemas joven que le dio a Bun buena parte de su rendimiento inicial, pero que combina manejo manual de memoria con el recolector de basura de JavaScriptCore, el motor de JavaScript que usa el runtime. Jarred Sumner, creador de Bun, explicó que esa combinación es un terreno resbaladizo: «mezclar recolección de basura con memoria administrada manualmente es algo lo suficientemente poco común como para que ningún lenguaje esté realmente diseñado para eso». El resultado fueron bugs recurrentes de use-after-free, double-free y fugas de memoria en subsistemas como zlib, HTTP/2 y sockets UDP, responsables de caídas reportadas hasta la versión 1.3.14.
Qué problema resuelve el cambio de lenguaje
Rust incorpora un verificador de préstamos (borrow checker) y el trait Drop, que fuerzan garantías de seguridad de memoria en tiempo de compilación en lugar de depender de revisiones de código y guías de estilo. Según Bun, «una gran parte de los bugs de esa lista son use-after-free, double-free y ‘me olvidé de liberar’ en un camino de error; en Rust seguro, estos son errores de compilación».
El equipo también reporta mejoras de rendimiento: entre +2,8% y +4,8% en throughput HTTP según el framework de servidor, entre +2,2% y +4,7% en herramientas de build sobre proyectos reales, un arranque 10% más rápido en un despliegue de producción de Claude Code, y una reducción de tamaño de binario cercana al 20%.
Cómo se hizo la reescritura y el rol de la IA
El dato que más llamó la atención de la comunidad no fue el destino sino el método: la migración de cerca de 535.000 líneas de Zig se hizo con asistencia intensiva de IA, en un proceso de 11 días entre el 3 y el 14 de mayo de 2026, con 6.502 commits en cuatro worktrees en paralelo y un costo aproximado de 165.000 dólares en llamadas a la API. El pull request se fusionó al repositorio principal el 14 de mayo, con 99,8% de compatibilidad con la suite de tests existente en Linux x64 con glibc.
El contexto no es menor: Anthropic adquirió Bun (la empresa Oven) el 2 de diciembre de 2025, su primera adquisición, en momentos en que Claude Code (que se distribuye como un ejecutable de Bun) superaba los 1.000 millones de dólares de ingresos anualizados.
Qué implica para el ecosistema JS/Node/Deno y qué sigue
La versión 1.3.14 quedó como la última compilada en Zig, y Bun ya liberó builds canary en Rust apenas publicado el anuncio, con la versión estable proyectada como 1.4.0. Para el resto del ecosistema, el movimiento refuerza a Rust como lenguaje de referencia para reescrituras de infraestructura crítica (algo que Node.js y Deno vienen observando de cerca en sus propias piezas de bajo nivel) y deja un antecedente concreto de una reescritura de gran escala hecha en días con asistencia de IA, un escenario que hasta hace poco parecía hipotético para un proyecto de este tamaño.
Qué mirar si tu equipo evalúa runtimes JS
Para equipos de la comunidad MUG que hoy corren Node, Deno o Bun en producción, el anuncio no cambia nada de un día para el otro: los binarios canary recién arrancan y la migración completa a Rust todavía tiene que probarse a escala fuera de los benchmarks propios de Bun. Pero sí es una señal para sumar a la lista de seguimiento antes de la próxima decisión de stack, sobre todo si la estabilidad de memoria fue alguna vez motivo de dolores de cabeza en producción.
¿Cambiaría tu equipo de runtime JS por una promesa de menos bugs de memoria, o prefiere esperar a que la reescritura se pruebe en producción por más tiempo?
Fuentes
- Bun Blog — Rewriting Bun in Rust
- The Register — Anthropic’s Bun Rust rewrite merged at speed of AI
- Simon Willison — Rewriting Bun in Rust
