Buz: un fork de Bun en Zig moderno que se reconstruye en menos de un segundo

Después de la migración de Claude Code a Bun (con corazón en Rust) la semana pasada, un miembro de la comunidad Zig anuncia Buz: un fork de Bun reescrito con las versiones recientes de Zig, prometiendo compilaciones incrementales en menos de un segundo. 224 puntos en la parte superior de Hacker News.

El caso concreto

Bun (el runtime JavaScript concurrente de Node) está escrito mayoritariamente en Zig, un lenguaje de sistema que seduce con su promesa de «hacer lo que hace C, pero mejor». Excepto que, a medida que Bun ha crecido, se ha quedado bloqueado en una versión relativamente antigua de Zig, con tiempos de compilación que se disparan al modificar aunque sea un solo archivo.

Entonces entra Buz, un fork anunciado por un miembro de la comunidad en ziggit.dev (el foro oficial de los zigueurs) el 24 de julio de 2026. El eslogan se resume en una línea: «drop-in replacement for Bun using modern Zig, with sub-1s incremental builds». En Hacker News, el anuncio alcanzó rápidamente 224 puntos y 161 comentarios —para un proyecto incipiente, es una señal.

Esto llega en un momento crucial para el ecosistema de Bun: la semana pasada, Simon Willison documentaba que Claude Code ahora usa Bun (con un núcleo en Rust), un signo de que Bun se está instalando en el ecosistema de IA. Cada fricción en la velocidad de contribución se convierte, por tanto, en un problema que va más allá del proyecto en sí.

Lo que hay que entender

El nombre del proyecto, Buz («Bun» + «Zig»), no es solo un juego de palabras. Documenta la apuesta técnica:

• Seguir las versiones recientes de Zig (el lenguaje está en pre-1.0, los cambios disruptivos son frecuentes, pero las optimizaciones del compilador avanzan rápido).
• Aprovechar el compilador autoalojado de Zig, que ofrece compilaciones incrementales dignas de ese nombre.
• Mantener la compatibilidad de API con Bun para no fragmentar el ecosistema (como hace Deno vs. Node).

El punto clave son esas compilaciones incrementales de menos de un segundo. Cuando se trabaja en un runtime tan grande, cada ciclo «cambio una línea → pruebo» cuenta. Pasar de varias decenas de segundos a menos de un segundo cambia por completo la ergonomía de contribución: es el tipo de detalle que decide si un proyecto atrae a desarrolladores externos o queda atrapado en su equipo fundador.

El verdadero debate

Los comentarios en HN están divididos en dos bandos:

1. Los entusiastas — un fork mantenido por la comunidad puede desbloquear cosas que Jarred Sumner (fundador de Bun) nunca tuvo tiempo de abordar. Ejemplo notable: los forks OpenSSL/LibreSSL o io.js, que obligó a Node.js a reaccionar.
2. Los escépticos — el riesgo de divergencia es real. Un «drop-in replacement» que falla en un 5 % de las APIs termina creando más problemas de los que resuelve. Y mantener un fork activo de un proyecto tan grande como Bun requiere mucha gente.

Nuestra lectura

Probablemente sea más interesante como prueba de concepto que como competidor serio de Bun. Si Buz demuestra que se pueden tener compilaciones de menos de un segundo en una base de código de este tamaño, el equipo de Bun tendrá todo el interés en integrar esas optimizaciones aguas arriba, beneficiando a todos. El patrón «fork que empuja al original a moverse» es una constante en el software libre.

A vigilar: la frecuencia de commits en las próximas semanas. Un fork que se apaga tras 15 días es común; uno que resiste tres meses ya empieza a contar.

Para recordar Buz aún no es un reemplazo creíble de Bun, pero señala un problema real: el estancamiento de la versión de Zig que usa Bun frena la velocidad del proyecto. Ya sea que Buz tenga éxito o no, el efecto mecánico será forzar a Bun a migrar más rápido, lo que también se relaciona con el nuevo posicionamiento de Bun en el ecosistema de IA (Claude Code).