Buz – un fork de Bun compatible avec le Zig le plus récent et des builds incrémentaux en moins d’une seconde

• Buz est un fork encore à un stade précoce, lancé à partir du commit de Bun juste avant sa réécriture en Rust, avec pour objectif de devenir un remplaçant compatible basé sur le Zig le plus récent
• L’ensemble du graphe de build, jusqu’aux sources vendorisées de JavaScriptCore, a été déplacé vers build.zig, et de petits patchs ont été appliqués à Zig pour obtenir des builds incrémentaux en moins d’une seconde
• Les tests des nouvelles fonctionnalités et correctifs de bugs du Bun en version Rust ont été repris, mais beaucoup échouent encore, ce qui impose de continuer à suivre les fonctionnalités upstream et les changements de JavaScriptCore
• Plus de 11 000 lignes de code inutilisées ont été supprimées, et plusieurs bugs ont aussi été corrigés au passage lors de la modernisation de certaines implémentations autour de la bibliothèque standard de Zig
• Le projet n’est pas encore utilisable en production, et l’objectif à long terme est de réduire la dette technique avec l’aide conjointe des LLM et de la supervision humaine pour aboutir à une base de code maintenable sans LLM

---

Objectifs du projet et état du développement

• Buz est un fork en cours de développement basé sur le dernier commit de Bun avant sa réécriture en Rust
• Le projet vise à être un remplaçant compatible de Bun tout en construisant une base de code plus propre que l’existante
• Le développement en est à un stade très précoce, donc il n’est pas prêt pour un usage en production
• Buz a été rendu public pour éviter la duplication du travail de développement alors qu’un projet Bun similaire basé sur Zig avait déjà été publié sur Ziggit
  • Au moment de la publication, ce projet n’avait pas encore été examiné

Portage vers le Zig actuel et builds incrémentaux

• Bun a été porté vers la version upstream actuelle de Zig, avec de petits patchs appliqués à Zig pour permettre les rebuilds incrémentaux
• L’ensemble du graphe de build, y compris les sources vendorisées de JavaScriptCore, a été intégré dans build.zig
• Avec cette configuration, le temps de build incrémental tombe à moins d’une seconde, ce qui accélère fortement les cycles d’itération
• Le projet inclut un sous-module Zig master avec le patch de build incrémental appliqué
• Il se compile aussi correctement avec le commit upstream Zig 2b1c663 de l’époque

Tests de compatibilité et suivi de l’upstream

• Les tests ajoutés à la version Rust de Bun ont été repris, y compris de nombreux tests vérifiant les nouvelles fonctionnalités et corrections de bugs
• Beaucoup de tests ne passent pas encore, il faut donc continuer à rattraper l’upstream de Bun
• Le travail de nettoyage du code et de réduction de la dette technique se poursuit en parallèle du maintien de la compatibilité fonctionnelle
• Les changements de JavaScriptCore doivent eux aussi être suivis en continu

Nettoyage et modernisation de la base de code

• Plus de 11 000 lignes de code totalement inutilisé dans Bun ont été supprimées
• Certaines parties du code ont été réécrites et modernisées, avec un usage accru de la bibliothèque standard de Zig
• Plusieurs bugs ont également été corrigés pendant ce travail de nettoyage et de modernisation
• La base de code existante de Bun représente environ 600 000 lignes, et atteindre un état vraiment propre nécessitera selon l’auteur de réécrire un nombre important de sous-systèmes

Usage des LLM et politique de contribution

• Le projet prévoit de faire un usage intensif des LLM pour remettre en ordre une base de code existante complexe, tout en y ajoutant supervision humaine et meilleures pratiques de développement
• Tant que la base de code ne sera pas jugée suffisamment propre, les contributions écrites directement par des humains ne seront pas acceptées
• La priorité est donnée à la réduction de la dette technique et à l’écriture d’un code Zig idiomatique, avec pour objectif d’aboutir d’ici quelques semaines ou quelques mois à une alternative compatible au Bun Rust 1.4.0
• Le projet demande l’aide de développeurs capables d’utiliser Sol ou Fable
• À long terme, l’objectif est de construire une base de code facile à maintenir sans l’aide des LLM, tout en renforçant les compétences en Zig au fil du développement

[GN⁺]

Commentaires Hacker News

• Le fait le plus intéressant de ce fork, c’est qu’il a prouvé que Bun aurait aussi pu compiler rapidement depuis longtemps
  la compilation incrémentale de Zig ne prend pas encore en charge aarch64 et le patch binaire n’est possible qu’avec le linker Linux, mais la prise en charge des principales plateformes semble n’être qu’une question de temps
  • Vu le tollé autour du fork du compilateur Zig pour accélérer la compilation, il est surprenant que ce ne soit pas le commentaire le mieux classé
    Le fait qu’une équipe d’une seule personne ait atteint une compilation en 1 seconde montre que la lenteur des builds était le résultat de pratiques de développement négligentes, et que consacrer du temps au fork était une très mauvaise allocation des ressources
• Nettoyer avec un LLM le code cassé par un LLM, on dirait que la technologie a atteint son apogée en 2026
  • Jusqu’ici, les humains ont aussi nettoyé le code cassé par des humains, donc il n’y a pas de contradiction logique
  • Les résultats d’un LLM sont aussi bons que les compétences de l’utilisateur qui le pilote
  • Je suis sceptique vis-à-vis de l’IA, mais prêt à l’utiliser, et si un LLM peut vraiment nettoyer ses propres résultats, cela pourrait changer la donne
  • J’avais la même impression, mais juste après, il dit qu’un humain gardera la main, réduira la dette technique et écrira du code Zig plus permissif pour produire, en quelques semaines ou quelques mois, une base de code capable de remplacer Rust Bun 1.4.0
    Au fond, cela semble vouloir dire donner plus d’instructions, ou de meilleures instructions. La structure du code relève aussi un peu des préférences ; hier encore, j’ai eu une conversation absurde avec quelqu’un qui insistait sur le fait qu’il fallait quatre processus backend pour traiter une seule requête HTTP
  • C’était dans cette direction depuis le début. Des sorties LLM cassées, illisibles et incompréhensibles pour les humains deviennent du code, donc au final tout le code ne pourra qu’être fait pour être lu et écrit par des machines
    L’époque où les humains intervenaient n’a été qu’une phase transitoire, dès le départ
• Je suis surpris qu’en supprimant 11 000 lignes de code complètement mort de Bun et en le modernisant pour mieux utiliser la bibliothèque standard, ils aient aussi corrigé une foule de bugs
  C’est courant dans les gros projets, ou bien c’est juste moi qui ne le savais pas ?
  • L’ensemble fait 600 000 lignes, donc le code mort représente environ 1,8 %. Plus la base de code est grande, plus il faut examiner large pour déterminer si du code est réellement inutilisé ; avec le temps, des changements éloignés peuvent aussi créer du code mort, donc c’est plus fréquent
    On ne sait pas s’il s’agit de code évident comme if (false) { dead_code(); }, ou de code qui peut être atteint par dispatch dynamique mais qui, en pratique, ne peut jamais être appelé selon la logique. Dans le premier cas, 1,8 % est élevé ; dans le second, c’est peut-être faible. Beaucoup de projets accumulent aussi du code placé derrière d’anciens feature flags, pratiquement jamais exécuté
    Laisser un peu de code mort, comme de petits utilitaires ou du code généré, n’est pas forcément un problème, mais sa suppression peut aussi entraîner des suppressions en cascade et des simplifications
  • Dans ma précédente entreprise, on a réduit un composant de 10 000 lignes à 2 000 tout en corrigeant tous les bugs majeurs
    À strictement parler, ce n’était pas du code mort, mais quand on nettoie une petite mauvaise abstraction, l’occasion d’en nettoyer d’autres s’ouvre à la suite, et au final il ne reste qu’un logiciel qui fait vraiment ce qu’il est censé faire. Les bases de code ont tendance à enfler avec le temps, donc à l’échelle de Bun, le plus étonnant est plutôt de n’avoir trouvé que 11 000 lignes
  • Le compilateur Zig fait de la compilation paresseuse, donc il ne détecte pas les fonctions mortes non appelées depuis une quelconque fonction compilée
  • Vu la manière dont Bun est développé, c’est moins que prévu, et il doit en rester bien davantage dans la base de code
  • Ce qui m’étonne, c’est qu’on soit surpris par cette quantité de code mort dans une grande base de code. Cela correspond à peine à une dizaine de PR de taille normale
• Je me demande combien d’années de programmation il faut avoir pour considérer 11 000 lignes de code mort comme quelque chose d’aussi exceptionnel
  • J’ai plus de 10 ans d’expérience. Je parlais de code manifestement mort qui n’est appelé depuis nulle part, et je me demandais s’il existe vraiment beaucoup d’autres projets avec autant de cas
• Dans tous les projets de codage centrés sur les agents, il y avait une sorte d’oscillation tic-tac entre développement de fonctionnalités et gestion du code
  Pendant la phase tic, on ajoute vite des fonctionnalités pour produire une version correcte mais extrêmement sale ; pendant la phase tac, on digère et on nettoie le résultat pour améliorer les performances, la maintenabilité et la résistance au changement
  Je passais souvent une journée à faire du vibe coding pour obtenir une appli fonctionnelle, puis une semaine à en faire un projet sur lequel on peut continuer à ajouter des fonctionnalités sans qu’il s’effondre comme un château de cartes. C’était déjà un peu le cas avant l’IA, mais les développeurs expérimentés avaient un modèle mental plus solide du système et avançaient plus lentement, donc la bascule n’était pas aussi brutale
  • Au final, il faut quand même relire le code soi-même pour vérifier que la logique n’est pas dupliquée partout et que c’est réellement maintenable
    Les modèles de codage ont une forte tendance à emprunter des raccourcis qui cassent l’encapsulation ou à dupliquer du code qui ne devrait pas l’être
• J’ai envie d’appeler ça de la programmation de performance ostentatoire. J’aime les performances, et les temps de build devraient eux aussi être proches de 0, mais on est désormais dans la zone des rendements décroissants, et le goulot d’étranglement actuel n’est probablement pas le temps de build
  • Les développeurs de Bun ne seraient pas d’accord, puisqu’ils ont eux-mêmes subi de longs temps d’attente sans pouvoir tirer parti de la compilation incrémentale : https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    Sur les gros projets, on ne peut pas attendre plusieurs minutes à chaque fois qu’on lance des tests ou qu’on vérifie des erreurs sémantiques, donc le temps de build est clairement un goulot d’étranglement
  • Pour ce type de projet, des builds rapides sont indispensables, et c’est une étape importante pour rendre la maintenance plus facile
• Si Bun est maintenu par quelqu’un qui attache de l’importance à la qualité du code, tant mieux, mais c’est une tâche herculéenne
  • Plus qu’herculéenne, c’est presque une tâche sisyphéenne sans fin
• J’aimerais voir aussi, à l’inverse, un fork Zig n’acceptant que des contributions IA
  Non pas parce que je soutiens fortement l’IA, mais comme art conceptuel ou expérience, ce serait amusant de voir comment les deux projets évoluent différemment
• Cruller, très lié au sujet, utilise aussi la base de code de Bun avant la réécriture, mais se concentre uniquement sur la partie runtime destinée à la production
  Lien : https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  Discussion HN : https://news.ycombinator.com/item?id=49017344
• Je ne comprends pas pourquoi Bun suscite autant d’attention. Pourquoi ne pas simplement rester sur Node + npm + Vitest + Vite ?
  • Il existe le projet Nub, qui cherche à apporter à Node les avantages de Bun, et qui peut aussi bien montrer pourquoi les gens préfèrent Bun ainsi que l’écart avec les outils existants
    https://nubjs.com
  • C’est justement cette énumération qui explique l’engouement. Au lieu d’assembler une multitude d’outils, on peut utiliser un runtime unique qui fait tout ce dont on a besoin
    Composer des outils spécialisés n’a rien de mauvais, mais c’est extrêmement pratique quand tout fonctionne d’emblée. Le bundler de Bun expose aussi une API runtime, ce qui permet au même processus qui sert les assets de coordonner un bundler externe, ou de bundler directement en mémoire sans écrire de fichiers statiques sur disque
  • Le simple fait de devoir lister quatre outils montre à quel point la situation existante est mauvaise
  • On ne sait même plus vraiment pourquoi il faudrait continuer à utiliser npm