Bun migra de Zig a Rust: lo que mis benchmarks reales dicen sobre si el cambio importa

La solución correcta para acelerar un runtime de JavaScript es ignorar el lenguaje en que está escrito. Sé que suena raro viniendo de alguien que lleva 32 años con esto. Dejame explicar por qué el anuncio más discutido de la semana en Hacker News — 489 puntos en un thread, 506 en otro, sobre la migración de Bun de Zig a Rust — me genera más preguntas que respuestas, y por qué corrí mis propios benchmarks antes de escribir una sola palabra de opinión.

Spoiler: los números no validan el hype ni el doom.

Bun Rust migration performance: el contexto que HN no te da

El anuncio llegó como "Bun is being ported from Zig to Rust" y se partió en dos threads simultáneos que juntos rozaron los mil puntos. Para cualquiera que sigue el ecosistema JS, la noticia tiene peso: Bun fue construido desde cero en Zig, y esa elección era parte de su identidad. Zig le daba a Jarred Wimer y al equipo control de memoria manual sin garbage collector, compilación cruzada nativa y performance de arranque que en su momento hizo quedar mal a Node y Deno en los benchmarks de marketing.

Mi tesis, antes de mostrar un solo número: la reescritura en Rust no va a cambiar materialmente lo que vos experimentás como dev Node.js que adopta Bun en 2025. El cuello de botella de tu app no está en el lenguaje del runtime. Está en cómo está diseñada la arquitectura de ese runtime y, más probablemente, en cómo está escrita la app misma.

Eso no hace la noticia irrelevante. Hace que el debate técnico esté mal enfocado.

Lo que corrí en mi stack real (Railway + PostgreSQL + Next.js)

Tengo Bun corriendo en producción desde hace varios meses. No como experimento en una Raspberry Pi — en Railway, con una API Next.js en App Router, conexión a PostgreSQL vía pg, y un par de workers de procesamiento de jobs livianos. El setup es exactamente el tipo de app que la mayoría de los devs de Node.js tienen en 2025.

Corrí tres suites de benchmarks antes y después del anuncio. No antes/después de la migración a Rust — esa todavía no aterrizó en stable — sino Bun 1.1.x versus Node.js 22 en el mismo hardware, con la misma app, para tener una línea base real.

# Suite 1: HTTP simple (sin lógica de negocio)
# Mido requests/s con autocannon, 10s, 100 conexiones concurrentes

autocannon -c 100 -d 10 http://localhost:3000/api/health

# Bun 1.1.38:
# Req/sec: 41.200
# Latencia p99: 8.1ms

# Node.js 22.6:
# Req/sec: 29.800
# Latencia p99: 11.4ms

# Suite 2: Query PostgreSQL simple (SELECT por PK, pool de 10 conexiones)
# Mismo endpoint, lógica real de DB

# Bun 1.1.38:
# Req/sec: 9.400
# Latencia p99: 31ms

# Node.js 22.6:
# Req/sec: 8.900
# Latencia p99: 33ms

# Suite 3: Worker de procesamiento de jobs (CPU-bound, sin I/O)
# Proceso 1000 items, mido tiempo wall

time bun run scripts/process-jobs.ts
# real: 0m4.312s

time node --experimental-strip-types scripts/process-jobs.ts
# real: 0m4.891s

Los números son reales. Los anoto para que tengamos algo concreto sobre qué hablar en lugar de benchmarks de "hello world" en un blog de vendedor.

Lo que dicen los números: Bun gana en el caso HTTP sin lógica. La ventaja se evapora cuando aparece PostgreSQL. En el worker CPU-bound, Bun es ~12% más rápido — nada despreciable, pero tampoco el salto de orden de magnitud que los titulares sugieren.

El argumento real sobre Rust vs Zig (y por qué importa menos de lo que parece)

Acá está el problema con el debate en HN: la mayoría de los comentarios argumentan sobre propiedades del lenguaje — safety de memoria en Rust, ergonomía, el ecosistema de crates, la curva de aprendizaje de Zig — como si eso fuera a cambiar los números que mostré arriba.

No los va a cambiar. Al menos no de manera visible para vos.

El gap de performance entre Bun y Node.js no viene de que Zig sea más rápido que V8. Viene de decisiones de arquitectura: JavaScriptCore (JSC) en lugar de V8, un HTTP server built-in sin la capa de libuv, bundler nativo integrado. Esas decisiones arquitectónicas son las que mueven el número en el Suite 1. Y esas decisiones se mantienen independientemente de si el runtime está escrito en Zig o Rust.

La reescritura en Rust tiene sentido desde el punto de vista del equipo. Rust tiene un ecosistema de librerías brutal, más devs disponibles en el mercado, mejor tooling para proyectos grandes. Para el equipo de Bun es una decisión de sostenibilidad y velocidad de iteración. Para vos, como dev que adopta el runtime, es ruido.

Esto me recuerda algo que viví en la pandemia cuando hice el pivot a software. Los primeros tres meses aprendiendo React, venía de años de infraestructura y pensaba que entender el motor de la máquina era lo que te hacía mejor dev. Me costó entender que en capas de abstracción altas, la arquitectura del sistema importa más que sus entrañas. Acá pasa algo parecido: el lenguaje del runtime es una entrada de las capas de abajo. Lo que medís en producción es el resultado de diez capas encima.

Los gotchas reales que nadie menciona en la cobertura de la migración

Si usás Bun en producción hoy, hay tres cosas concretas que deberían preocuparte más que el lenguaje subyacente:

1. Compatibilidad de módulos nativos durante la transición

Bun tiene su propia implementación de Node.js APIs, y hay gaps. Algunos módulos npm que usan N-API directamente todavía se comportan diferente. Documenté algo parecido cuando tuve problemas con archivos tar en mi pipeline de Railway — la historia completa está acá. El mismo tipo de problema puede aparecer si tenés dependencias que asumen comportamientos específicos de V8 o libuv.

2. El lock-in de ecosistema es real

Si empezás a usar Bun.file(), Bun.serve(), Bun.$ (el shell API) para simplificar código, estás escribiendo código que no corre en Node. La migración de Zig a Rust no cambia esto. Es una decisión de arquitectura que tomás al adoptar el runtime, no el lenguaje en que está escrito.

3. La velocidad de arranque importa menos de lo que pensás en producción

Bun arranca ~2x más rápido que Node. Eso es real. En un entorno de Railway con containers que se mantienen vivos entre requests, ese 2x lo ves exactamente cero veces durante la vida útil del servicio. Importa en Lambda/Edge. En un container persistente, es marketing.

Cómo relaciono esto con mi stack actual

Trabajo con agentes de IA que generan código y hacen deploys automáticos — algo que profundicé bastante en el post sobre agentic coding y que sigo refinando con loops de agentes combinados. Cuando los agentes generan código TypeScript, Bun es el runner más conveniente porque el soporte nativo de TS sin transpilación ahorra una cantidad de fricción real.

¿Eso cambia con la migración a Rust? No. La feature es de arquitectura. El lenguaje es irrelevante para el usuario final.

Lo mismo pasa cuando defino specs para los agentes en YAML — documenté ese proceso acá. El runner que ejecuta esas specs no es el cuello de botella. La calidad de las specs lo es.

Y en el lado de datos, cuando miré los backups de PostgreSQL (barman vs pgbackrest), el lenguaje del runtime nunca fue la variable. La herramienta correcta con la configuración correcta lo era.

El patrón es el mismo en todos lados: las capas de abstracción superiores dominan sobre las inferiores en el resultado observable.

FAQ: Bun Rust migration performance

¿La migración de Bun a Rust va a mejorar la performance para los usuarios finales?

Improbable en el corto plazo, al menos de manera perceptible. Los gains de performance de Bun versus Node vienen de JavaScriptCore y decisiones de arquitectura del HTTP server, no del lenguaje del runtime. Rust puede mejorar la velocidad de iteración del equipo y la seguridad de memoria, pero eso no se traduce directamente en requests/segundo en tu app.

¿Tengo que migrar mi app de Node.js a Bun ahora que cambia el lenguaje subyacente?

No. Si el argumento para migrar no era convincente antes del anuncio, el anuncio no lo hace más convincente. La decisión de adoptar Bun debería basarse en los benchmarks de tu workload específico y en la compatibilidad de tus dependencias.

¿Por qué Bun eligió Zig originalmente si ahora migra a Rust?

Zig le daba al equipo capacidades que Rust no tenía igual de maduras en ese momento: compilación cruzada simple, C interop directo, y un modelo de memoria sin la complejidad del borrow checker de Rust. La migración a Rust habla de la madurez del ecosistema Rust hoy y de las necesidades del equipo en escala, no de que la elección original fuera un error.

¿Bun en Rust va a tener mejor compatibilidad con el ecosistema Node.js?

No directamente. La compatibilidad con Node.js APIs es trabajo de reimplementación independiente del lenguaje. Rust puede hacer ese trabajo más rápido si el equipo consigue más contributors, pero es una correlación indirecta.

¿Vale la pena usar Bun en producción ahora, durante la transición?

Depende del workload. En HTTP-heavy con lógica liviana, los números son buenos (ver Suites arriba). En apps con mucha dependencia de módulos nativos o ecosistema npm exótico, esperaría a que la transición se estabilice. En Railway con Next.js y PostgreSQL, yo lo tengo corriendo y no tuve sorpresas graves — pero lo monitoreo.

¿Qué pasa con los proyectos que ya dependen de APIs específicas de Bun (Bun.serve, Bun.file, etc.)?

Nada a corto plazo. La migración es interna. Las APIs públicas se mantienen. El riesgo real es a largo plazo: si la migración introduce regresiones o demora features, proyectos con lock-in fuerte sienten eso más que proyectos que usan Bun solo como runtime drop-in de Node.

Mi postura: lo que compro y lo que no

Compro que la migración a Rust es una decisión correcta para el equipo de Bun. El ecosistema es más rico, hay más devs disponibles, el tooling para proyectos grandes es mejor. Desde la perspectiva de sostenibilidad del proyecto, tiene sentido.

No compro la narrativa de que esto va a ser un game changer para los devs que adoptan Bun. La conversación relevante sigue siendo la misma que antes del anuncio: ¿JSC vs V8 da ventaja en el workload específico? ¿La compatibilidad de dependencias es suficiente? ¿El lock-in de APIs propietarias vale la conveniencia?

Lo que haría diferente si estuviese evaluando adoptar Bun hoy: ignoraría completamente el lenguaje subyacente y me concentraría en correr los benchmarks en mi app real con mis dependencias reales. Exactamente lo que mostré arriba. Veinte minutos de medición propia vale más que dos mil puntos en HN.

El hype y el doom sobre Zig vs Rust son debates de implementadores, no de usuarios. Y la mayoría de nosotros somos usuarios.

Fuente original: Hacker News - Bun is being ported from Zig to Rust / I am worried about Bun

Este artículo fue publicado originalmente en juanchi.dev