Où en est la réécriture de Bun en Rust ?

• Présentée comme un travail achevé en 11 jours, elle n’a pourtant toujours pas de tag de release le 27 juillet 2026, six semaines après la fusion dans main, et les travaux associés se poursuivent
• La réécriture initiale a coûté 165 000 dollars en frais d’API Anthropic du 3 au 14 mai 2026, mais les coûts de CI/CD Buildkite et des travaux de suivi ne semblent pas inclus
• Les PR ouvertes de robobun sont passées de 1 277 le 9 juillet à 2 475 le 27 juillet ; si chaque pipeline par PR prend environ 40 minutes, il faudrait 86 jours d’exécution continue pour toutes les traiter
• L’utilisation de Claude a bondi au début de la réécriture et la participation de robobun ainsi que d’employés d’Anthropic aux travaux Rust a augmenté, ce qui rend difficile d’affirmer que la date d’achèvement et le coût total réel se limitent à 165 000 dollars
• L’équipe Bun n’ayant pas elle-même affirmé que la réécriture était terminée ni fixé un coût total, utiliser les performances du codage par IA comme base de valorisation d’entreprise impose d’examiner aussi la valeur par rapport au coût et l’intervention humaine continue

---

Une réécriture qui continue après la fusion

• Dans Rewriting Bun in Rust, Jarred Sumner indique avoir dépensé 165 000 dollars en appels à l’API Anthropic pendant 11 jours, du 3 au 14 mai 2026, puis fusionné le résultat de la réécriture dans main
  • Cela représente environ 15 000 dollars par jour, un niveau difficilement supportable pour beaucoup de mainteneurs open source
  • Les coûts de CI/CD apparemment générés en continu sur le cluster Buildkite de l’organisation ne semblent pas inclus dans ce chiffre
• Au 27 juillet 2026, six semaines se sont écoulées depuis la fusion, mais aucun nouveau tag de release n’est disponible ; 11 semaines se sont écoulées depuis le dernier tag, bun-v1.3.14
  • La précédente période de plus d’un mois sans release remontait à l’intervalle de six semaines entre v0.2.2, le 26 octobre 2022, et v0.3.0, le 7 décembre
• Les PR ouvertes de robobun, indicateur indirect des PR créées par Claude Code, sont passées de 1 277 le 9 juillet à 2 475 le 27 juillet
  • Les vérifications Buildkite et la fusion dans main prennent généralement environ 40 minutes, parfois jusqu’à 1 h 30, d’après les observations
  • En appliquant 40 minutes par PR, fusionner les 2 475 PR nécessiterait 86 jours d’exécution continue du pipeline
  • Certaines PR ne sont pas liées au code Rust, et certaines PR individuelles ont fait l’objet de très nombreuses revues

Écart entre coûts publics et effort réel

• Au début de la réécriture, l’utilisation de Claude a fortement augmenté, puis la participation d’employés d’Anthropic et de robobun aux travaux Rust a également progressé
  • L’analyse inclut l’hypothèse selon laquelle les commits de Jarred Sumner pendant la période de réécriture utilisaient Claude
  • Certaines PR ayant été rédigées par des employés d’Anthropic, il faut prendre en compte non seulement le coût des tokens, mais aussi leur intervention directe
• En supposant que la réécriture continue de coûter 10 000 dollars par jour, le coût cumulé approcherait 800 000 dollars, mais il s’agit d’une estimation fondée sur une hypothèse, et non d’un coût réel publié
• L’équipe Bun n’a pas affirmé que la réécriture était entièrement terminée ni que le coût total se limitait à 165 000 dollars
  • Il est difficile de conclure, à partir de ce seul cas, que l’IA a remplacé plus rapidement le travail des mainteneurs open source
  • Anthropic applique ses propres outils en interne, tandis que les tâches automatisées et la participation des employés se poursuivent
• Plutôt que de rejeter l’IA elle-même, il faut se méfier des attentes excessives et des valorisations d’entreprise actuelles, et examiner si la valeur créée justifie les coûts engagés ainsi que la valorisation de ces entreprises
• Le C compiler d’Anthropic et le navigateur web FastRender de Cursor n’ont reçu aucun commit depuis plusieurs mois

[GN⁺]

Avis sur Hacker News

• La réécriture de Bun en Rust tourne depuis plus d’un mois dans Claude Code, mais presque personne ne s’en est rendu compte, et dans l’ensemble elle fonctionne bien.
  Elle ne sera pas publiée tant qu’elle n’aura pas passé autant de tests de compatibilité Node.js que promis dans la vidéo de Bun v1.4 ; si la PR correspondante est fusionnée, il est très probable que la v1.4 sorte vers mardi prochain.

  • Pour la qualité du logiciel, il faut pouvoir prendre le temps nécessaire. Un mois sans sortie n’a rien de dramatique, et si une fonctionnalité donnée est urgente, on peut contribuer soi-même ou faire son propre build.
    Node.js lui-même, hors correctifs de sécurité, n’a pas de sorties significatives pendant 4 à 6 semaines chaque décembre ; cette critique, qui commence par un billet énervé sans même demander aux principaux intéressés, repose donc sur des bases fragiles. Je le dis en tant que mainteneur de Node.js.
  • Claude Code lui-même a souvent des bugs et des incidents après release, il n’est donc pas surprenant que les utilisateurs n’aient pas distingué les bugs dus au passage de Bun à Rust des bugs habituels.
  • Je me demande s’il est possible de répondre aux estimations de coût de l’article, en particulier les coûts Buildkite.
  • Je comprends pourquoi on peut s’inquiéter de l’avenir de Bun : beaucoup de projets de vibe coding démarrent très fort puis peuvent être abandonnés, comme le C d’Anthropic. Bun est rapide et agréable à utiliser, j’espère donc qu’il durera longtemps, comme GCC.

• Juste après un gros refactoring ou une réécriture, il faut du temps pour retrouver le rythme de développement habituel ; il est donc difficile de déduire grand-chose du seul nombre de commits et du cycle de publication.
  Même si les développeurs connaissent bien l’architecture, ils doivent s’adapter à une base de code Rust, et il est très possible qu’ils se concentrent sur des tâches comme le suivi des usages de unsafe plutôt que sur des fonctionnalités utilisateur. Comme le canal canary n’a quasiment pas révélé de gros problèmes ni de changements majeurs, ils ont de bonnes raisons de traiter l’arriéré plutôt que de publier dans la précipitation.
  J’ai vu le compilateur C d’Anthropic et le navigateur FastRender de Cursor non pas comme des projets destinés à durer, mais comme des expériences de capacité ; j’espère que personne ne les utilise directement aujourd’hui.

  • Tous les utilisateurs de Claude Code ont été migrés vers la nouvelle version il y a un mois ; dans un certain sens, il y a donc déjà eu une mise en production réelle. Comme le sujet attire beaucoup d’attention et qu’il n’y a pas besoin de se presser pour une sortie officielle, ils semblent avancer progressivement.
  • L’angle des coûts CI/CD est intéressant. D’ordinaire, quand on conteste le retour sur investissement de l’IA, on dit que produire plus de code n’augmente pas forcément la valeur ; mais si chaque exécution de CI est facturée, le chiffre d’affaires augmente réellement.
    Cela rejoint aussi le fait que la CI et les tests supplémentaires sont essentiels pour éviter que le travail répétitif produit par l’IA ne devienne incontrôlable.
  • Même du point de vue de l’auteur de l’article, il n’est pas certain que ces chiffres permettent de conclure grand-chose. J’espère qu’après la prochaine sortie, Anthropic ou Bun publieront un post-mortem détaillant le coût total.

• Traduire rapidement un projet avec un LLM, ou produire d’un coup un clone de suite bureautique, est en soi impressionnant ; mais l’essence du logiciel n’est pas la génération initiale rapide, c’est le développement de fonctionnalités et la maintenance à long terme.
  On peut fabriquer assez vite les fonctions de base d’un clone de Word, mais dès qu’on touche aux détails — structure des pages, tableaux, images, rotation — les LLM commencent à s’effondrer. Même si l’on portait SQLite de C vers Rust en faisant passer tous les tests, il risquerait d’être lent faute des années d’optimisation de l’implémentation existante, et il faudrait aussi assumer les nouveaux bugs liés au changement de langage ainsi que le support futur.
  Sur Reddit, on voit sans cesse passer des projets affirmant avoir implémenté X, Y ou Z, mais la correction de bugs, la relation avec les utilisateurs, la sécurité, les structures de données qui évoluent et le travail sur les bases de données sont moins séduisants ; ils finissent donc souvent abandonnés aussi vite qu’ils ont été produits en vibe coding.
  Si l’on ne comprend pas en profondeur le logiciel que l’on a créé, il finit par exploser ; une phrase du type « réécrire X en Z en Y jours » ne veut rien dire à elle seule. Accélérer le départ et comprendre, faire évoluer puis maintenir le code porté sont deux choses totalement différentes ; au lieu de la version Zig maintenue, une version Rust abandonnée et des billets promotionnels peuvent finir par polluer les résultats de recherche.

  • J’aimerais que davantage de personnes documentent ce processus. Personnellement, je développe un projet qui dépend beaucoup des LLM et j’apprends en chemin : quand des fonctionnalités complexes se mettent vite à fonctionner, c’est extrêmement grisant, mais l’intégration, le nettoyage et le polissage de l’UI deviennent presque plus pénibles après avoir goûté à cette vitesse initiale.
    Quand le code s’emmêle trop dans des solutions provisoires, on atteint un point d’inertie où le LLM ne peut plus avancer sans créer encore plus de confusion ; il faut alors corriger l’architecture, tout jeter et recommencer, ou revenir au dernier état qui fonctionnait correctement. C’est comme développer avec un jetpack : on atteint plus vite l’objectif, mais on percute aussi les murs plus vite et plus douloureusement.
    Les débats sur le fait que l’IA soit la meilleure ou la pire chose, et la compétition autour des bonnes pratiques d’utilisation des outils, masquent le manque d’informations sur ce qui fonctionne ou échoue réellement, et sur la façon dont il faut modifier son comportement en les utilisant. J’essaie moi aussi d’écrire un retour d’expérience, mais je repousse parce qu’il est plus amusant d’ajouter une fonctionnalité ou de corriger un défaut d’UI.
  • GitHub comptait déjà, avant les LLM, des milliers de moteurs de jeu et de compilateurs pour langages imaginaires abandonnés. Au début des années 2000, sur les forums consacrés aux systèmes d’exploitation, presque tout le monde écrivait son propre OS, et certains arrivaient même à lancer Firefox.
    Tous les logiciels n’ont pas besoin d’être commerciaux ou très aboutis pour être utiles ; de simples expériences d’apprentissage permettent déjà d’apprendre énormément.
  • Plus on va profondément dans la technique, plus on risque d’être considéré comme remplaçable. C’est parce qu’on accepte l’hypothèse selon laquelle, dans une organisation, la valeur vient de la compétence technique pure, et non de soi-même ou de ses relations.
    Mais on semble commencer à admettre que des facteurs contingents comme les effets de réseau, la propriété et la responsabilité comptent aussi. Il y a toutefois un paradoxe : beaucoup de techniciens sont justement entrés dans le domaine technique pour fuir le népotisme, les évaluations arbitraires et les environnements où le bluff compte plus que la compétence technique.
  • J’ai travaillé dans une startup qui a entièrement réécrit une grosse base de code, au point de suspendre aussi le développement de fonctionnalités ; mais comme je m’occupais d’un autre projet, j’ai raté tout le processus, et quand je suis revenu, la courbe d’apprentissage était presque inexistante. Le langage avait changé, mais l’architecture centrale, les structures de données et les concepts étaient les mêmes.
    Bun n’a pas non plus été repensé depuis zéro : il a d’abord été porté tel quel vers un nouveau langage. Même d’après l’expérience d’avant les LLM, pour faire basculer rapidement une équipe, la bonne approche consiste à porter aussi simplement et rapidement que possible vers un autre langage ; minimiser les X jours de réécriture est un bon objectif.
  • Ne pas chercher à comprendre en profondeur le code que l’on écrit relève d’un court-termisme extrême. Les mainteneurs vont apprendre difficilement où se situe la frontière entre du code généré par IA et du code maintenable par des humains.

• Quelqu’un affirme avoir modernisé l’implémentation Zig d’origine et appliqué les bonnes pratiques pour corriger des bugs, tout en obtenant des builds incrémentaux en moins d’une seconde. Cela suggère que les problèmes qui justifiaient la réécriture étaient en réalité auto-infligés et pouvaient être résolus.
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  La version Zig utilise elle aussi des LLM, cela n’a donc rien à voir avec une guerre culturelle. Quelqu’un qui comprend vraiment le domaine du problème a toujours pu obtenir de meilleurs résultats qu’une personne se contentant d’y déverser des ressources, comme des centaines de milliers de dollars en tokens.

  • Le cœur de l’argument justifiant la réécriture n’était pas la vitesse de build, mais les bugs mémoire, en particulier lors des interactions avec des objets JavaScript gérés par garbage collection. Zig n’a pas de moyen général de les empêcher, et on ne voit pas non plus d’affirmation selon laquelle Buz aurait résolu ce point.
  • Ce projet ressemble davantage à un mème ou à une blague qu’à une tentative sérieuse. Il qualifie les 600 000 lignes existantes de code chaotique généré par IA, et déclare qu’il refusera les contributions écrites par des humains jusqu’à ce que la plupart des sous-systèmes aient été réécrits.
    Il est difficile de prendre au sérieux un projet qui veut nettoyer du code chaotique avec des LLM tout en interdisant les contributions humaines.

• Grâce à la réécriture de Bun, il est devenu possible de tenter bien plus audacieusement le portage et la réécriture de code, ainsi que la vendoring de dépendances externes, et de se spécialiser pour des besoins internes même si cela ne convient pas aux projets amont.
  Tout en confiant des tâches plus ambitieuses aux modèles de codage, l’attention s’est beaucoup plus portée sur les dispositifs de test et la validation hors des frontières du langage. Ayant aussi participé à de grandes réécritures sur plusieurs années, je considère Bun, qui a maintenu les tests et la parité fonctionnelle tout en ajoutant des améliorations, comme une réussite d’ingénierie impressionnante.

• Les discussions autour de la réécriture de Bun comportent beaucoup d’accusations dramatiques et d’attaques personnelles, chacun semblant y projeter des préoccupations idéologiques plus profondes. Ce texte se montre sceptique quant à la capacité de l’IA à remplacer efficacement les programmeurs, tandis que l’argument du mainteneur de Zig portait davantage sur l’éthique et l’avenir de l’open source à l’ère des LLM.
  Pour ceux qui sont optimistes sur les capacités de l’IA, il n’y a pas vraiment de raison de douter qu’un développeur expérimenté puisse guider un LLM de pointe pour traduire une bibliothèque entière. Les questions de suivi les plus importantes concernent le coût actuel et la possibilité d’une fracture future entre les camps adoptant pleinement l’IA et ceux qui ne l’adoptent pas.

  • Il n’y avait aucune personne expérimentée en Rust dans l’équipe.
  • Le portage Zig→Rust de Bun apporte peu d’enseignements généralisables sur Zig, Rust, le portage entre langages ou l’usage des LLM. Les bases de code avant et après comportent trop de caractéristiques difficiles à quantifier, et les préférences concernant les langages, les méthodes de portage et le codage avec LLM entrent aussi en jeu.
    Si l’on n’obtient pas le même résultat, ou si le coût en tokens est plus élevé, on peut dire que l’outil a été mal utilisé ; si le résultat déçoit, on peut s’en sortir en disant qu’il ne s’agissait que d’une preuve de concept et que les modèles se sont améliorés ces six derniers mois, rendant la comparaison impossible. Il est donc difficile d’obtenir des conclusions vérifiables.
  • Les LLM excellent à produire des résultats plausibles mais faux, il y a donc beaucoup de raisons d’être sceptique. Indépendamment de la véracité du résultat, cette opération est clairement une opération marketing, et Anthropic ayant déjà fait des annonces exagérées ou inexactes, une vérification plus rigoureuse est nécessaire.

• Je soupçonnais que l’annonce criant victoire, et même l’analyse approfondie qui paraissait honnête, étaient quelque peu prématurées.
  Le principal risque de la hype autour des LLM est qu’elle donne des gains immédiats aux développeurs expérimentés fatigués de taper et de réfléchir manuellement, tout en utilisant comme garantie des décennies d’expérience logicielle accumulée. La vraie facture arrive bien plus tard.

  • La frappe au clavier est secondaire en génie logiciel, mais les LLM peuvent avoir de la valeur dans les situations où elle constitue réellement le goulot d’étranglement. Ces situations sont toutefois rares.

• Le texte gagnerait en crédibilité s’il mentionnait que Bun basé sur Rust est en production dans Claude Code depuis le 17 juin et qu’il a aussi été proposé en version canary après son arrivée dans main. Pour une réécriture de cette ampleur, une longue période canary est tout à fait justifiée.

  • Le texte traite déjà de l’usage interne réel chez Anthropic.

• Anthropic n’a peut-être pas vraiment intérêt à publier publiquement la prochaine version. La version Rust tourne depuis plus d’un mois dans Claude Code, utilisé par des millions de personnes, et l’objectif de l’acquisition de Bun était probablement Claude Code.
  Le projet open source lui-même n’est peut-être pas si important pour eux.

  • Si seul Claude Code comptait vraiment, il aurait été beaucoup plus efficace de réécrire Claude Code lui-même en Rust plutôt que de changer le langage du runtime TypeScript. Le coût d’environ 800 000 dollars provenait probablement du budget marketing d’Anthropic, avec l’objectif d’un gros effet de communication.
  • Il est peu probable qu’ils abandonnent la communauté au sens large, et plus il y a d’autres utilisateurs, plus Anthropic y gagne aussi. Si cette sortie pose problème, ils s’exposeront à de fortes critiques et la confiance de la communauté sera abîmée ; ils semblent donc plus prudents qu’à l’habitude.
  • Bun étant un composant majeur de l’écosystème web, le simple fait qu’Anthropic le développe avec l’IA produit un énorme effet de communication.
  • Claude Code devrait pouvoir s’exécuter sur n’importe quel runtime JavaScript ; je me demande donc pourquoi Bun était nécessaire.
  • Au final, cela ressemble à une opération marketing pour promouvoir la réécriture de code basée sur Claude. Le message selon lequel il faut dépenser beaucoup d’argent chez Anthropic pour se débarrasser d’une base de code inconfortable est bien passé.
    Si Claude Code était l’objectif, il aurait suffi de commencer par le réécrire ; et s’ils insistent sur le fait qu’ils n’écrivent plus directement de code, le langage d’implémentation ne devrait pas non plus avoir d’importance.

• Quiconque a déjà réécrit un logiciel peut comprendre l’étape actuelle. La plupart des choses fonctionnent, mais il faut continuer à corriger pour éviter les régressions, et la pression liée à la sortie est très forte.
  Je pense que la décision de réécrire était la bonne, mais je ne voudrais pas la déployer en production dès le départ. Si Jarred proposait d’abord une release candidate plutôt qu’une version stable immédiate, cela réduirait la pression.