De nos jours, les plateformes de réseaux sociaux sont souvent le spectacle d’échanges “musclés” (plutôt “orduriers” en réalité) sur n’importe quel sujet un tant soit peu clivant. Les batailles d’opinions font rage et le monde des dev n’en est pas exempt. Il y a quelques temps, la réécriture de Bun en Rust a fait couler beaucoup d’encre. Si je ne suis pas adepte de ces “dramas”, cette histoire met en lumière la place croissante de l’IA dans le développement, avec des dérives qui méritent qu’on s’y attarde.

Mea Culpa : de l’art de justifier la fuite

L’article sur la réécriture de Bun commence par un mea culpa de Jarred Sumner, affirmant que les difficultés rencontrées par Bun avec Zig (surtout des bugs de mémoire comme des use after free ou des fuites) proviennent de lui plus que d’une supposée faiblesse du langage qu’est Zig. Une élégante manière de ne pas directement déclarer la guerre à la communauté Zig, mais aussi d’éluder tout un pan du problème.

En lisant la réponse d’Andrew Kelley, on peut constater que le problème va au-delà d’un manque de maîtrise de Zig, car Bun aurait tout simplement choisi de ne pas prendre en compte les conseils de la communauté Zig sur son code. Un code jugé rempli de manipulations douteuses et à la qualité discutable, d’après Andrew Kelley. Alors oui, une réécriture complète pourrait régler ce problème de code peu qualitatif, mais pourquoi forcément sortir de Zig ? Quid de la tentative de fork de Zig réalisée quelque temps avant ?

Avec l’appui d’Anthropic, Bun disposait de ressources colossales, tant au niveau des tokens qu’au niveau de la puissance des modèles disponibles. Il est donc nécessaire de se demander ce qui justifie une réécriture de centaines de milliers de lignes en Rust, quand une chasse aux fuites mémoire et un accompagnement par la communauté Zig étaient envisageables. Et les réponses à ces questions se trouvent toutes dans la manière dont l’article de Bun aborde cette réécriture.

Publicité sous couvert d’article technique

Quand on prend l’article de Bun dans sa globalité, une réalité s’impose assez vite : il s’agit avant tout d’une démonstration de force pour Fable 5, l’outil de génération de code agentique le plus performant d’Anthropic mis à disposition du public, testé à grande échelle pour prouver son efficacité. Et c’est une stratégie payante, car Bun bénéficie d’une communauté et d’une visibilité suffisante pour qu’une réécriture complète attire les regards de tout le monde. Sans parler de la position de Zig vis-à-vis de l’usage de l’IA dans le code. Bref, un coup marketing assuré.

Entre les illustrations issues de playground Claude, les chiffres fièrement annoncés de tokens dépensés et d’agents Fable en parallèle, il est difficile de douter quant à l’implication d’Anthropic dans ce projet et dans l’article lui-même. Il est d’ailleurs intéressant de voir comment l’article met en avant la programmation agentique soutenue par les tests unitaires déjà présents, tout en défendant le choix du langage Rust pour la réécriture. La stratégie consistant en la réécriture de tous les aspects d’une codebase aussi large en même temps fait qu’il est impossible pour un humain d’en lire tous les changements. Dès lors, et encore une fois, pourquoi ne pas rester sur Zig ? En quoi Zig est-il un moins bon choix pour écrire du code memory-safe que Rust ?

L’article de Bun consacre toute une section à la question “Pourquoi Rust ?”. Mais les arguments sont selon moi assez pauvres, et l’article d’Andrew Kelley pointe bien cela du doigt. En effet, Andrew Kelley souligne l’incohérence de poser un choix binaire entre la mise en place d’un “guide style” et la sécurité offerte par une erreur à la compilation. Si souligner cela est pertinent, on peut pousser la réflexion plus loin : pourquoi s’échiner à choisir Rust pour sa sécurité mémoire native si le code n’est plus relu par des humains, mais couvert par des batteries de tests exécutés par une IA ? Cela revient à utiliser Rust comme un argument d’autorité, plus que comme une solution technique pertinente.

Selon moi, la réponse tient surtout dans l’étendue de responsabilité que l’on veut donner à l’IA, quand il s’agit de travailler à la place des humains. Mais, dans le cas de Bun (et donc d’Anthropic), le choix de Rust comprend certains effets de bord non négligeables.

Mettre la poussière sous le tapis de Rust

J’ai déjà mentionné plus tôt le coup marketing qu’Anthropic réalise au travers de cette vaste réécriture. Mais ce n’est pas, toujours selon moi, le seul avantage que Bun pourrait tirer de cette opération.

Premier gain : couper le cordon avec la communauté Zig. Exit la mauvaise presse sur la qualité douteuse du code, dont pourraient témoigner les membres de cette communauté. Exit aussi le rejet que pouvait exprimer la communauté vis-à-vis de Bun et de l’image qu’il donnait au langage qui le composait jusqu’à il y a peu. C’est d’ailleurs un point qu’Andrew Kelley mentionne dans son article, se disant “soulagé” de voir Bun, “l’exemple de ce qu’il ne faut pas faire en Zig”, quitter la communauté.

Deuxième gain : accélérer sur le IA-driven development. La mauvaise presse et le rejet de la part de la communauté Zig étaient en partie dus à la volonté de Bun de maximiser l’usage de l’IA dans son développement. Sortir de Zig permet donc de s’éloigner d’un conflit idéologique naissant avec sa communauté et de pousser toujours plus l’usage de l’IA dans son code, surtout maintenant qu’Anthropic chapeaute le tout.

Troisième gain : enterrer l’échec du fork. Vouloir développer Bun et maintenir un fork de Zig était un projet pour le moins ambitieux. Il est dommage de ne pas y consacrer ne serait-ce qu’une section dans l’article, voire un article à part entière (j’ose croire qu’une action de cette ampleur puisse en faire l’objet). Cependant, ne pas en parler revient à passer sous silence la volonté de Bun d’aller à l’encontre de la philosophie de Zig concernant l’usage de l’IA.

La réponse d’Andrew Kelley

Du côté d’Andrew Kelley, le propos est intéressant, même si je trouve que la forme dessert un peu le fond. Dans un article qui se veut être la réponse à un exposé technique, il est dommage de ne pas choisir de rester factuel. Les propos concernant l’évolution de sa relation avec Jarred Sumner ne sont pas nécessaires à une analyse, voire un debunk, du contenu de l’article (l’article de Bun est d’ailleurs assez impersonnel, je trouve). Néanmoins, la réponse, malgré ses quelques éléments superflus, a toute une section consacré à la manière dont Bun traite son sujet : “Addressing the blog post”.

Conclusion

Au-delà d’une très classique bataille d’égos, la réécriture de Bun montre un aspect dérangeant de notre ère : celui où la réécriture technique d’un projet open source devient un prétexte publicitaire pour un géant de l’IA.

Il est possible que mes attentes envers l’article de Bun aient été mal placées, mais lorsque j’ai entendu dire que Bun était réécrit en Rust, je ne m’attendais pas à voir des envolées lyriques sur Fable et des extraits de prompts. Jusqu’à présent, un sujet d’ampleur comme la réécriture complète d’un projet exposait très largement les difficultés rencontrées et les apprentissages que l’on peut tirer d’avoir construit un projet sur des bases peu solides pour ensuite tenter de le consolider. Là où j’attendais une petite épopée aux allures programmatiques, je n’ai trouvé qu’une pub opportune.