Buz : un fork de Bun en Zig moderne qui rebuild en moins d'une seconde

Après la migration de Claude Code vers Bun (avec cœur Rust) la semaine dernière, un membre de la communauté Zig annonce Buz : un fork de Bun réécrit avec les versions récentes de Zig, promettant des builds incrémentaux sub-seconde. 224 points en tête de Hacker News.

Le cas concret

Bun (le runtime JavaScript concurrent de Node) est écrit majoritairement en Zig, un langage système qui séduit par sa promesse « faire ce que fait C, mais mieux ». Sauf qu'à mesure que Bun a grossi, il s'est retrouvé bloqué sur une version relativement ancienne de Zig, avec des temps de compilation qui explosent quand on modifie ne serait-ce qu'un fichier.

Entre alors Buz, un fork annoncé par un membre de la communauté sur ziggit.dev (le forum officiel des zigueurs) le 24 juillet 2026. Le pitch tient en une ligne : « drop-in replacement for Bun using modern Zig, with sub-1s incremental builds ». Sur Hacker News, l'annonce a rapidement atteint 224 points et 161 commentaires - pour un projet naissant, c'est un signal.

Ça tombe dans un moment charnière pour l'écosystème Bun : la semaine dernière, Simon Willison documentait le fait que Claude Code utilise désormais Bun (avec un cœur Rust) - signe que Bun s'installe dans l'outillage IA. Chaque friction sur la vitesse de contribution devient donc un enjeu au-delà du seul projet.

Ce qu'il faut comprendre

Le nom du projet, Buz (« Bun » + « Zig »), n'est pas juste un jeu de mots. Il documente le pari technique :

• Suivre les versions récentes de Zig (le langage est en pré-1.0, les breaking changes sont fréquents mais les optimisations du compilateur avancent vite).
• Exploiter le compilateur auto-hébergé de Zig, qui apporte des builds incrémentaux dignes de ce nom.
• Rester compatible API avec Bun pour ne pas fragmenter l'écosystème (comme le fait Deno vs Node).

Le nerf de la guerre, ce sont ces builds incrémentaux sub-seconde. Quand on hacke sur un runtime aussi gros, chaque cycle « je change une ligne → je teste » compte. Passer de plusieurs dizaines de secondes à moins d'une seconde change complètement l'ergonomie de contribution - c'est le genre de détail qui décide si un projet attire des devs externes ou reste bloqué chez son équipe fondatrice.

Le vrai débat

Les commentaires HN sont divisés en deux camps :

1. Les enthousiastes - un fork tenu par la communauté peut débloquer des choses que Jarred Sumner (fondateur de Bun) n'a jamais eu le temps d'attaquer. Précédent notable : les forks OpenSSL/LibreSSL, ou io.js qui a forcé la main à Node.js.
2. Les sceptiques - le risque de divergence est réel. Un « drop-in replacement » qui rate 5 % des APIs finit par créer plus de problèmes qu'il n'en résout. Et maintenir un fork actif d'un projet aussi gros que Bun demande du monde.

Notre lecture

C'est probablement plus intéressant comme preuve de concept que comme concurrent sérieux à Bun. Si Buz démontre qu'on peut avoir des builds sub-seconde sur une base de code de cette taille, l'équipe Bun aura tout intérêt à remonter les optimisations upstream - ce qui bénéficierait à tout le monde. Le pattern « fork qui pousse l'original à bouger » est une constante dans le libre.

À surveiller : la fréquence des commits sur les prochaines semaines. Un fork qui s'éteint après 15 jours, ça arrive tout le temps ; un fork qui tient 3 mois commence à compter.

À retenir Buz n'est pas encore un remplaçant crédible de Bun, mais il pointe un vrai problème : la stagnation de la version Zig utilisée par Bun freine la vélocité du projet. Que Buz réussisse ou pas, l'effet mécanique sera de forcer Bun à migrer plus vite - ce qui fait aussi le lien avec le nouveau positionnement de Bun dans l'outillage IA (Claude Code).