Buz: fork de Bun compatible con Zig moderno y builds incrementales en menos de 1 segundo

• Buz es un fork en etapa inicial que parte del commit inmediatamente anterior a la reescritura de Bun en Rust, y se desarrolla con el objetivo de ser una alternativa compatible basada en Zig moderno
• Trasladó todo el grafo de build, incluido el código vendorizado de JavaScriptCore, a build.zig, y aplicó pequeños parches a Zig para lograr builds incrementales en menos de 1 segundo
• Importó pruebas de nuevas funciones y correcciones de bugs de la versión en Rust de Bun, pero muchas todavía fallan, por lo que debe seguir de cerca las funciones upstream y los cambios en JavaScriptCore
• Eliminó más de 11,000 líneas de código sin uso y, al modernizar algunas implementaciones alrededor de la biblioteca estándar de Zig, también corrigió varios bugs
• Aún no es apto para producción; su objetivo a largo plazo es reducir la deuda técnica usando LLMs junto con supervisión humana, y luego crear una base de código fácil de mantener incluso sin LLMs

---

Objetivos del proyecto y estado de desarrollo

• Buz es un fork en desarrollo basado en el último commit antes de que Bun fuera reescrito en Rust
• Se enfoca en ser una alternativa compatible con Bun y, al mismo tiempo, en crear una base de código más ordenada que la existente
• El desarrollo está en una etapa muy temprana, por lo que no está listo para usarse en producción
• Buz se publicó para evitar duplicar esfuerzos, ya que en Ziggit ya se había presentado un proyecto similar de Bun basado en Zig
  • Al momento de publicarlo, ese proyecto aún no había sido revisado

Port a Zig moderno y builds incrementales

• Bun fue portado al Zig upstream actual, y se aplicaron pequeños parches a Zig para permitir rebuilds incrementales
• Todo el grafo de build, incluido el código vendorizado de JavaScriptCore, se integró en build.zig
• Con esta configuración, el tiempo de build incremental se redujo a menos de 1 segundo, acelerando el ciclo de iteración durante el desarrollo
• El proyecto incluye un submódulo de Zig master con el parche de build incremental aplicado
• En ese momento, también podía compilarse correctamente con el commit upstream de Zig 2b1c663

Pruebas de compatibilidad y seguimiento de upstream

• Se importaron pruebas añadidas a la versión en Rust de Bun, incluidas muchas que verifican nuevas funciones y correcciones de bugs
• Todavía hay muchas pruebas que no pasan, por lo que debe seguir alcanzando a Bun upstream
• En paralelo, se trabaja en ordenar el código y reducir la deuda técnica manteniendo la compatibilidad funcional
• También será necesario seguir continuamente los cambios de JavaScriptCore

Limpieza y modernización de la base de código

• Se eliminaron más de 11,000 líneas de código que Bun no usaba en absoluto
• Algunas partes del código se reescribieron y modernizaron, aumentando el uso de la biblioteca estándar de Zig
• Durante el proceso de limpieza y modernización también se corrigieron varios bugs
• La base de código existente de Bun tiene alrededor de 600,000 líneas, y se considera que para llegar a un estado ordenado habrá que reescribir una cantidad importante de subsistemas

Uso de LLMs y política de contribuciones

• Para ordenar el código heredado complejo se planea usar LLMs de forma amplia, junto con supervisión humana y mejores prácticas de desarrollo
• No se aceptarán contribuciones escritas directamente por personas hasta que se considere que la base de código está suficientemente ordenada
• La prioridad es reducir la deuda técnica y escribir código Zig idiomático, con el objetivo de contar en semanas o meses con una base de código que pueda presentarse como reemplazo compatible de Rust Bun 1.4.0
• Se solicita ayuda de desarrolladores que puedan usar Sol o Fable
• A largo plazo, se busca crear una base de código fácil de mantener incluso sin ayuda de LLMs, y también mejorar las habilidades en Zig durante el proceso

[GN⁺]

Opiniones en Hacker News

• Lo más interesante de este fork es que demostró que Bun también podría haberse compilado rápido desde hace tiempo.
  La compilación incremental de Zig todavía no soporta aarch64 y el parcheo de binarios solo es posible con el linker de Linux, pero el soporte para las plataformas principales parece cuestión de tiempo.
  • Con todo el alboroto alrededor de haber hecho un fork del compilador de Zig para acelerar la compilación, sorprende que este no sea el comentario principal.
    El hecho de que un equipo de una sola persona haya logrado builds de 1 segundo muestra que las builds lentas eran resultado de prácticas de desarrollo descuidadas, y que dedicar tiempo al fork fue una asignación de recursos totalmente equivocada.
• Que ahora estén limpiando con LLM el código que rompió un LLM… parece que en 2026 llegamos a la cúspide de la tecnología.
  • Hasta ahora los humanos también venían limpiando código que otros humanos rompían, así que no hay contradicción lógica.
  • El resultado de un LLM es tan bueno como la capacidad del usuario que lo dirige.
  • Soy escéptico con la AI, pero estaría dispuesto a usarla; si un LLM realmente puede limpiar sus propios resultados, eso podría cambiar las reglas del juego.
  • Pensaba lo mismo, pero justo después dice que los humanos tomarán el control, reducirán la deuda técnica y escribirán código Zig idiomático para crear, en semanas o meses, una base de código capaz de reemplazar al Bun 1.4.0 en Rust.
    Al final parece que significa dar más instrucciones, o mejores. La estructura del código también parece una cuestión de gustos; ayer tuve una conversación absurda con un amigo que insistía en que para manejar una sola solicitud HTTP se necesitaban cuatro procesos de backend.
  • Desde el principio iba en esta dirección. Como salidas rotas de LLM, con forma de software pero imposibles de leer o entender para humanos, se están convirtiendo en código, al final todo el código terminará hecho para que las máquinas lo lean y lo escriban.
    Creo que la era en la que intervenían humanos fue una etapa temporal desde el inicio.
• Sorprende que hayan eliminado de Bun 11.000 líneas de código completamente muerto y, al modernizarlo para aprovechar más la biblioteca estándar, también hayan corregido muchísimos bugs.
  Me pregunto si esto es común en proyectos grandes y simplemente yo no lo sabía.
  • El total es de 600.000 líneas, así que el código muerto es aproximadamente el 1,8%. Cuanto más grande es una base de código, más amplio hay que mirar para determinar si el código realmente no se usa, y con el tiempo los cambios lejanos también pueden generar código muerto, así que es más común.
    No queda claro si era código obvio como if (false) { dead_code(); }, o código que podría invocarse mediante dispatch dinámico pero que lógicamente nunca puede llamarse. Si es lo primero, 1,8% es alto; si es lo segundo, podría ser bajo. Muchos proyectos acumulan código detrás de feature flags viejos que, en la práctica, nunca se ejecutará.
    Está bien dejar pequeñas cantidades de código muerto, como utilidades simples o código generado, pero a veces eliminarlo desencadena una cadena de eliminaciones y simplificaciones.
  • En una empresa anterior reduje un componente de 10.000 líneas a 2.000 líneas y corregí todos los bugs importantes.
    Estrictamente hablando no era código muerto, pero al limpiar una pequeña abstracción equivocada se abren una tras otra nuevas oportunidades de limpieza, y al final queda software que solo hace lo que se pretendía. Las bases de código se hinchan con el tiempo, así que en el caso de Bun me sorprende más que solo hayan encontrado 11.000 líneas.
  • Como el compilador de Zig hace compilación diferida, no detecta funciones muertas que no son llamadas desde ninguna función compilada.
  • Considerando la forma de desarrollo de Bun, es menos de lo que esperaba; probablemente quede mucho más en la base de código.
  • Lo sorprendente es que a alguien le sorprenda esta cantidad de código muerto en una base de código grande. Equivale apenas a unos 10 PR de tamaño normal.
• Me pregunto cuánta experiencia en programación tiene alguien para ver 11.000 líneas de código muerto como algo tan excepcional.
  • Tengo más de 10 años de experiencia. Me refería a código muerto evidente que no se llama desde ningún lado, y me preguntaba si hay otros proyectos con tanto de eso.
• En cada proyecto de coding centrado en agentes apareció una oscilación tic-tac entre desarrollo de funcionalidades y gestión del código.
  En la fase tic se agregan funcionalidades rápidamente para producir una versión correcta pero extremadamente desordenada; en la fase tac se digiere y ordena el resultado para mejorar rendimiento, mantenibilidad y fragilidad ante cambios.
  A veces se crea en un día una app funcional con vibe coding, y luego se pasa una semana convirtiéndola en un proyecto al que se le puedan seguir agregando funciones sin que se derrumbe como un castillo de naipes. Antes de la AI ya pasaba algo parecido, pero los desarrolladores profesionales tenían un modelo mental más fuerte del sistema y trabajaban más lento, así que el cambio no era tan brusco.
  • Al final hay que revisar el código directamente y confirmar que la lógica no esté duplicada por todos lados y que realmente sea mantenible.
    Los modelos de coding tienden mucho a tomar atajos que rompen la encapsulación o a copiar código que no debería duplicarse.
• Quiero llamar a esto programación de rendimiento ostentosa. Me gusta el rendimiento y los tiempos de build también deberían acercarse a 0 segundos, pero ya entramos en una zona de rendimientos decrecientes y el cuello de botella actual probablemente no sean los tiempos de build.
  • Los desarrolladores de Bun, que sufrieron directamente largas esperas sin poder aprovechar la compilación incremental, no estarían de acuerdo: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    En proyectos grandes no se puede esperar varios minutos cada vez que se ejecutan pruebas o se revisan errores semánticos, así que el tiempo de build es claramente un cuello de botella.
  • En proyectos así, las builds rápidas son esenciales, y lo veo como un paso importante para facilitar el mantenimiento.
• Un Bun mantenido por alguien que valora la calidad del código sería bienvenido, pero es una tarea hercúlea.
  • Más que hercúlea, se parece a una tarea de Sísifo que se repite sin fin.
• También me gustaría ver lo contrario: un fork de Zig que solo acepte contribuciones de AI.
  No tanto porque apoye fuertemente la AI, sino porque como arte conceptual o experimento sería interesante ver cómo evolucionan de forma distinta los dos proyectos.
• El muy relacionado Cruller también usa la base de código de Bun previa a la reescritura, pero se enfoca solo en la parte del runtime para producción.
  Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  Discusión en HN: https://news.ycombinator.com/item?id=49017344
• No entiendo por qué Bun genera tanto ruido. Me pregunto si no podríamos simplemente volver a Node + npm + Vitest + Vite.
  • Existe el proyecto Nub, que busca llevar las ventajas de Bun a Node, y también puede mostrar bien por qué la gente prefiere Bun y cuál es la brecha con las herramientas existentes.
    https://nubjs.com
  • Precisamente esa enumeración es la razón del ruido. En vez de combinar un montón de herramientas, puedes usar un solo runtime que haga todo lo necesario.
    No hay problema en combinar herramientas específicas para cada propósito, pero es muy cómodo que en el estado por defecto todos los problemas estén resueltos. El bundler de Bun también tiene una API de runtime, así que el mismo proceso que sirve assets puede hacer bundling directamente en memoria sin coordinarse con un bundler externo ni escribir archivos estáticos en disco.
  • El solo hecho de tener que enumerar cuatro herramientas muestra lo mala que es la situación actual.
  • Ahora tampoco queda claro por qué habría que seguir usando npm.