Le créateur de Zig dit la vérité, mais Anthropic fanfaronne

 (raymyers.org)
3 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Alors qu’Anthropic présente la fin du génie logiciel comme une valeur future, la transition de Bun de Zig vers Rust aurait aussi été utilisée dans un récit promotionnel suggérant que l’IA peut remplacer l’ingénierie
  • Bun a invoqué des bugs mémoire pour justifier ce changement, mais l’absence de comparaison des alternatives et de leurs compromis, ainsi que le fait de ne pas rendre publics certains coûts comme la lenteur de compilation de Rust, peuvent donner l’impression d’une justification a posteriori
  • Il existait aussi d’autres façons d’utiliser Zig, et le TigerStyle de TigerBeetle montre comment l’allocation mémoire statique et les tests par simulation peuvent empêcher les use-after-free
  • La migration fichier par fichier en unsafe Rust est une approche raisonnable pour réduire les risques et permettre une refonte ultérieure, mais accepter une conversion par IA à l’échelle d’un million de lignes tout en problématisant quelques lignes de gestion de pointeurs lisibles par un humain manque de cohérence
  • Comme les harnais d’agents, le borrow checker de Rust, les règles de lisibilité et la revue humaine restent nécessaires, adopter des agents de codage et abandonner le génie logiciel ne sont pas le même choix

La fin du génie logiciel mise en avant par Anthropic

  • Anthropic pousse activement le récit selon lequel, après le codage, le génie logiciel puis la plupart du travail humain disparaîtront
  • L’entreprise a levé 132 milliards de dollars et se rapproche d’une IPO valorisée à plus de 1 000 milliards de dollars, mais, dans une situation où elle ne parvient pas à démontrer sa rentabilité, elle doit vendre une influence future hypothétique
  • En raison de ces intérêts, Anthropic doit être vue comme un narrateur non fiable (unreliable narrator), et il importe de considérer non seulement la véracité de son message, mais aussi son effet sur le jugement des dirigeants, des responsables politiques mondiaux et des gestionnaires de fonds de retraite
  • Le récit autour de l’IA influence les décisions d’architecture, de produit et d’allocation des effectifs, et rend difficile un jugement lucide entre peur des licenciements, avertissements de prendre du retard et Doom Trolling
  • Pour évaluer l’IA dans le logiciel, un examen sceptique tenant compte des intérêts d’Anthropic et de ses objectifs promotionnels est nécessaire

La migration de Bun de Zig vers Rust et ses explications tardives

  • Anthropic/Bun n’a expliqué sa décision de migrer Bun, écrit en Zig, vers Rust que deux mois après l’avoir fusionnée dans la branche principale
    • Pour un grand projet d’infrastructure, il est généralement préférable d’expliquer la direction en amont
    • Pendant ce délai, des titres comme Anthropic’s Bun Rust rewrite merged at speed of AI ont diffusé l’impression que l’IA avait rapidement achevé la réécriture
  • Andrew Kelley, créateur de Zig, a publié une réponse et, sur un ton inhabituellement direct, a critiqué la technologie et le fonctionnement organisationnel de Bun
    • Il existe un risque réputationnel : cela pourrait créer un précédent où, au motif qu’un projet a changé de langage, le responsable du langage précédent s’attaque aussi aux défauts personnels des protagonistes
    • Certains ont parlé de “meltdown”, mais on peut aussi considérer qu’il a soulevé publiquement des problèmes qui devaient l’être

Critères pour juger une critique directe

  • La parole juste du bouddhisme (right speech) considère que toute prise de parole doit satisfaire cinq critères
    • Est-ce vrai ?
    • Est-ce utile ?
    • Est-ce opportun ?
    • Est-ce bienveillant ?
    • Est-ce motivé par la bienveillance ?
  • La réponse d’Andrew Kelley relève de la parole vraie mais peu bienveillante ; la question est de savoir s’il était nécessaire de signaler publiquement le problème, même au prix d’un écart par rapport à la courtoisie habituelle

Relation entre Bun, Zig et les politiques de contribution par IA

  • Bun est un runtime TypeScript souvent comparé à un NodeJS plus rapide, tandis que Zig est un langage de programmation système souvent comparé à un C moderne
  • Jusqu’à récemment, Bun était écrit en Zig et constituait l’une des plus grandes bases de code Zig
  • Les politiques des deux projets sur les contributions par IA sont diamétralement opposées
  • Après l’acquisition de Bun par Anthropic, son fondateur Jarred Sumner a mené une expérience d’agents à grande échelle pour migrer le code Zig vers de l’unsafe Rust, et le résultat a été fusionné quelques jours plus tard pour devenir la version officielle
  • Parmi les parties concernées, personne ne semble demander que Bun reste en Zig ; la controverse porte moins sur la transition elle-même que sur ses raisons et sa promotion
  • Une migration de langage à grande échelle au moyen d’agents est une expérience technique qui mérite d’être retentée dans des circonstances appropriées

Trois interprétations d’une même décision

  • Pour un développeur qui doit choisir entre Zig et Rust, le fait que l’un des plus grands utilisateurs de Zig soit revenu sur sa décision constitue un élément de jugement important
  • L’interprétation d’Anthropic/Bun est qu’ils ont essayé toutes les méthodes raisonnables, mais que Zig rendait les bugs mémoire difficiles à gérer
  • Selon l’interprétation d’Andrew Kelley, la base de code est devenue chaotique à cause des décisions d’ingénierie de Bun, notamment parce que des agents IA prenaient en charge une part excessive de l’écriture et de la revue de code
  • Une possibilité plus ordinaire est qu’il existait plusieurs solutions aux problèmes mémoire réels, mais que la direction a trouvé plus facile de choisir une réécriture en Rust
    • Cela permettait de promouvoir les capacités du nouveau modèle Fable
    • Anthropic utilisait déjà Rust
    • Le projet Zig s’oppose publiquement à l’utilisation des produits d’Anthropic
  • La migration vers Rust peut être rationnelle sur le plan business, mais la communication s’est concentrée sur la puissance supposée de l’IA, capable d’effectuer la réécriture
    • Le fait que l’IA n’ait pas détecté à l’avance les use-after-free contredit ce récit
  • L’exagération portée par le mégaphone d’Anthropic met directement en comparaison les jugements de Jarred Sumner et d’Andrew Kelley, et peut, involontairement, affecter aussi la réputation de Zig

Pourquoi la fiabilité personnelle est entrée dans le débat technique

  • Le premier acteur à tenir responsable n’est pas tant le fondateur de Bun à titre individuel que Anthropic, qui exploite cet épisode dans son récit sur l’IA
  • Dans la mesure où Anthropic utilise la crédibilité de Jarred Sumner pour renforcer son propre message, y répondre oblige aussi à évaluer son jugement et ses actions
  • Il serait préférable de ne discuter que des enjeux techniques, mais lorsque le message d’Anthropic repose davantage sur le spectacle et la promotion que sur la comparaison technique, la crédibilité personnelle entre elle aussi dans le débat
  • Si le simple fait de récapituler ce qu’une personne a publiquement dit et fait ressemble à de la diffamation, alors ces actions elles-mêmes font peut-être partie du problème

Crunch permanent et environnement organisationnel chez Bun

  • L’offre d’emploi publiée par Bun en 2022 avertissait que les neuf premiers mois seraient très éprouvants et que le poste ne conviendrait pas à ceux qui accordent de l’importance à un équilibre vie professionnelle/vie personnelle avec beaucoup de temps non travaillé
  • Le mode crunch permanent nuit à la fois à la santé et à la productivité, ce que confirment à plusieurs reprises les travaux empiriques sur le travail de la connaissance
  • Il faut choisir des managers qui protègent le sommeil de leur équipe la nuit plutôt que ceux qui se vantent de semaines de 90 heures
  • L’évaluation qu’Andrew Kelley dit avoir entendue de personnes liées à l’équipe Bun se résume à un manque de communication, des attentes irréalistes, une faible empathie et un manque d’expérience, mais elle a la limite d’un témoignage rapporté
  • Cela dit, cette évaluation est aussi cohérente avec les conditions de travail extrêmes rendues publiques dans l’offre d’emploi
  • De bonnes technologies peuvent émerger même dans un mauvais environnement de travail, et Bun lui-même est un outil utilisable et intéressant
  • L’idée que le code contenait beaucoup de bugs et était difficile à maintenir ne relève pas seulement d’une critique extérieure : c’est aussi l’état que Bun a lui-même avancé comme justification de sa migration vers Rust

Valeur pratique de la migration en Rust unsafe

  • Les détails techniques du processus de transition valent la peine d’être réutilisés dans d’autres projets de modernisation
  • Bun n’a pas été repensé dès le départ en Rust sûr : il a effectué une migration fichier par fichier vers unsafe Rust
    • Cela a conservé la structure existante et réduit le risque initial de transition
    • Cela a posé les bases pour améliorer ensuite la sûreté et repenser l’architecture
  • L’automatisation fondée sur l’IA pourrait rendre le choix d’un langage plus facilement réversible qu’auparavant, mais la réécriture automatique comporte toujours des avantages, des inconvénients et des écarts sémantiques
  • Il est également possible de combiner plusieurs techniques de réécriture et de les renforcer par des méthodes formelles (Formal Methods)
  • Le programme TRACTOR de la DARPA est un programme de recherche visant à transférer tout le code C vers Rust, et le rapport d’évaluation publié traite de l’état des techniques de conversion automatique
  • Même si les agents offrent davantage d’options pour le code ancien, définir des objectifs de modernisation exige toujours du jugement et de la communication

Un document de décision technique avec de nombreuses lacunes

  • Pour expliquer une décision technique, il faut au minimum trois éléments
    • Quelle est la motivation
    • Quelles alternatives ont été examinées
    • Quels sont les avantages et inconvénients de chaque alternative
  • Le document dans lequel Richard Feldman explique pourquoi il a migré le compilateur Roc de Rust vers Zig est un exemple comparatif qui réunit ces trois éléments
  • L’explication de Bun avance la motivation des bugs mémoire, mais ne traite qu’une partie des alternatives examinées, et la comparaison des avantages et inconvénients est quasiment absente
  • En particulier, omettre les avantages et inconvénients peut donner l’impression d’une justification a posteriori, où l’on fixe la réponse dès le départ avant d’y adjoindre des arguments
  • On ne peut pas exclure qu’il existe d’autres raisons non rendues publiques ; pour renforcer la crédibilité de la décision, il faut aussi exposer les coûts défavorables

Une comparaison qui ne liste que les avantages de Rust

  • La section « Bun is better in Rust » ne traite que les bénéfices du passage à Rust et présente très peu les coûts
  • Une grande base de code Rust obtient généralement de la sûreté au prix de temps de compilation plus lents
  • Bun a par le passé accordé de l’importance à la vitesse de compilation, au point d’essayer d’améliorer par 4 les temps de compilation en forkant le compilateur Zig
  • Si la migration vers Rust a augmenté le temps de build des contributeurs, le rendre public et expliquer pourquoi la sûreté compte davantage que ce coût renforcerait la crédibilité de la décision
  • En mélangeant dans la liste des avantages de la réécriture en Rust d’autres améliorations réalisées après la transition, l’effet direct du changement de langage peut être exagéré

Des options de guide de style non examinées

  • Dans Bun, les bugs mémoire n’étaient pas la seule source de défauts, mais selon un décompte personnel, ils étaient assez fréquents pour nécessiter 4 commits de correction par semaine
  • Chaque bug mémoire signifie qu’une convention sur la façon de créer, posséder et libérer des objets a été rompue quelque part ; on peut donc commencer par examiner des méthodes pour définir clairement le comportement attendu selon les situations
  • La gestion manuelle de la mémoire élargit le périmètre des conventions, mais quel que soit le langage, des consignes d’utilisation efficaces sont nécessaires ; Rust dispose lui aussi de recommandations de style pour les API

  • L’alternative montrée par TigerBeetle

    • TigerBeetle, autre base de code Zig emblématique, une base de données de transactions financières, ne souffre pas de bugs mémoire et semble être l’une des bases de données les plus fiables
    • Elle s’appuie sur TigerStyle et les tests par simulation comme fondements de sa fiabilité
    • TigerStyle n’est pas un simple style de codage, mais une philosophie d’ingénierie qui relie conception, mémoire et tests
    • Toute la mémoire est allouée statiquement au démarrage
    • Après l’initialisation, les allocations dynamiques et les réallocations après libération ne sont pas autorisées
    • Cela empêche les use-after-free tout en évitant les variations de performance difficiles à prévoir
    • En prenant en compte dès la conception les schémas possibles d’utilisation de la mémoire, cela encourage des structures plus simples, plus rapides, et plus faciles à raisonner et à maintenir
    • Toutes les applications ne peuvent pas appliquer cette méthode telle quelle, mais elle montre que la politique mémoire est liée aux décisions de conception globales

  • Les zones d’ombre qui restent dans l’explication de Bun

    • Après avoir mentionné TigerStyle et le guide de style C++ de Google en 31 000 mots, Bun conclut que les guides de style sont difficiles à faire respecter et que l’on s’appuie traditionnellement sur la revue de code, les linters et les analyseurs statiques
    • Mais Bun ne traite pas du guide de style qu’il utilisait réellement, des raisons de son échec, ni de la manière dont il l’a amélioré en quatre ans
    • Si les problèmes de mémoire ont persisté dans un grand projet, il est important de savoir si l’option consistant à utiliser différemment le langage actuel a été sérieusement testée, mais les éléments à l’appui manquent
    • Un mode de fonctionnement où une seule personne garde tout le contexte en tête et où il n’y a pas de réunions rend difficile la création de conventions explicites et d’une conception partagée

Contradiction entre revue par agents et guide de style

  • Bun estime que les guides de style sont difficiles à faire respecter, tout en déclarant avoir rédigé un PORTING.md pour la migration et que des agents ont relu l’ensemble du code réécrit selon des consignes strictes
  • Comme PORTING.md est lui-même un guide de style spécialisé pour le périmètre de la transition, si la revue par agents a réussi, cela signifie que le problème d’application des consignes était déjà résolu
  • Dans des conditions appropriées, la revue par agents peut fonctionner, mais elle suppose des règles et un mode de revue suffisamment conçus
  • Le même effort intellectuel aurait pu être consacré à la reconception du code Zig et au renforcement des conventions, mais Bun a choisi la réécriture plutôt que la refonte d’architecture
  • Pour diverses raisons non rendues publiques, la réécriture a pu être le bon choix, mais l’explication actuelle ne suffit pas à comparer les alternatives

Une réécriture d’un million de lignes et trois lignes de code de pointeurs

  • Bun considère que, pour rendre visibles au niveau des types les attentes de propriété dans Zig, il faudrait ajouter du code comme SharedPtr(TCPSocket) et deref(), ce qui serait moins pratique que l’usage existant des pointeurs
  • Dans cet exemple, clarifier le passage de pointeurs aux frontières d’interface ajoute environ trois lignes de code
  • Accepter une PR d’un million de lignes générée par IA et difficile à relire, tout en rejetant pour des raisons de lisibilité quelques lignes qui clarifient la propriété des pointeurs, manque de cohérence
  • Jarred Sumner a déclaré ne pas avoir saisi de code manuellement pendant plusieurs mois
  • Si le code n’est pas destiné aux humains, l’argument selon lequel le wrapper SharedPtr serait désagréable à lire s’affaiblit ; s’il est destiné aux humains, il faut continuer à tenir compte de la lisibilité, de la possibilité de revue et de la maintenabilité
  • Les entreprises d’IA rechignent à reconnaître que la lisibilité du code reste importante, mais nier ce point convient peut-être au récit de la fin du génie logiciel, tout en entrant en conflit avec la réalité de la maintenance
  • Il existe aussi un benchmark indiquant que les agents de codage peuvent, par défaut, dégrader la maintenabilité

Ce que révèle le même cas : « l’IA seule ne suffit pas »

  • La réécriture à grande échelle de Bun par des agents ne sert pas seulement à améliorer la technologie ; elle remplit aussi une fonction commerciale en promouvant le message d’Anthropic selon lequel « l’IA suffit »
  • Pourtant, le même exemple peut aussi être interprété à l’exact opposé
  • En partant du principe que les problèmes créés par les agents peuvent eux aussi être résolus avec davantage d’agents, la pratique consistant à acheter des tokens plutôt que de meilleurs outils, et à ajouter un SKILL.md plutôt que d’apprendre la technologie, se répand
  • Appeler Team des sessions parallèles d’agents, au lieu de comprendre la psychologie des équipes logicielles, revient à confondre organisations humaines et sessions d’exécution automatique

Adopter des agents de codage et abandonner l’ingénierie sont deux choses distinctes

  • La campagne d’Anthropic sur la fin de l’ingénierie logicielle peut avoir un effet contre-productif à la fois pour ceux qui conçoivent des outils d’IA et pour ceux qui les utilisent
  • Même en adoptant des agents de codage, il n’est pas nécessaire de prendre pour modèle idéal une Dark Software Factory où les humains ne comprennent pas le code
  • L’objectif est de construire ce que les gens veulent et de le faire fonctionner correctement ; la bulle de l’IA peut pousser à produire, avec une qualité médiocre, des choses dont on ne veut pas
  • Il faut utiliser l’IA sans pour autant renoncer au jugement, à l’apprentissage, à la communication, à la lisibilité et à la maintenabilité

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Réactions sur Hacker News

  • Cet article contient beaucoup de bonnes remarques, mais il fait penser à ces projets générés par IA qu’on abandonne après quelques mois. La valeur d’un projet tient moins à la quantité de code produite qu’au niveau de validation en conditions réelles qu’il a subi, et un code existant mature vaut mieux qu’une nouvelle réécriture
    Le codebase Zig existant a déjà été validé, alors que la réécriture en Rust n’a pratiquement aucune validation au-delà du passage des tests, et si elle a été faite comme une traduction quasi littérale fichier par fichier en unsafe Rust, on voit mal en quoi elle serait meilleure que le Zig de départ. Elle n’aura de sens qu’une fois progressivement migrée vers du Rust sûr puis validée en production et par de nombreux utilisateurs
    En pratique, c’est quasiment un fork de Bun, et peu importe qu’au final la version Zig ou la version Rust survive ; il n’y a pas de raison d’y voir un problème d’adéquation de Zig

    • Les projets IA sont abandonnés parce qu’ils sont générés dans l’instant. Le coût irrécupérable peut au contraire être un avantage en aidant à traverser les moments difficiles et les périodes creuses, mais on ne s’attache pas vraiment à un résultat produit à partir d’une idée passagère et de quelques prompts Claude
      Même en tant que développeur assez ordinaire, j’ai des dizaines d’idées géniales chaque jour, mais très peu résistent à l’examen, et quelques jours plus tard même celles-là ne semblent plus mériter l’effort. Les idées ont toujours été peu coûteuses, et maintenant les preuves de concept le sont aussi ; donc un Show HN dans lequel moins d’un mois a été investi ne m’intéresse pas
    • Pour arriver à un Rust sûr ayant réellement fait ses preuves en production, il faut bien commencer quelque part ; l’idée est donc de faire d’abord une traduction directe, puis d’améliorer progressivement
      Le camp Zig semble craindre que Zig soit une langue sans avenir dès le départ, parce qu’elle n’offre pas assez d’avantages par rapport au C pour être utilisée sérieusement et que même son projet emblématique est parti. En cherchant segfault dans le suivi des issues de Zig, on comprend pourquoi certains doutent de son utilité future face à des alternatives comme Rust
    • Contrairement à Zig, il existe désormais une frontière unsafe claire et de portée limitée, qu’on peut corriger point par point
    • L’introduction de l’article est excessivement cynique. Parmi les connaissances que j’ai chez Anthropic et OpenAI, ces gens croient réellement que, dans un avenir proche, les agents prendront en charge l’essentiel de la programmation et qu’eux-mêmes perdront leur emploi
      Il ne s’agit pas de cadrer le message pour faire la leçon au camp anti-IA
    • On ne peut pas affirmer avec certitude que les projets générés par IA sont vite abandonnés à cause d’un manque de validation en conditions réelles. La plupart des projets personnels ordinaires finissent eux aussi par être abandonnés au bout d’un certain temps, et comme il est désormais possible d’écrire du code beaucoup plus vite, on atteint peut-être simplement plus tôt le point de rendement marginal décroissant en termes d’utilité personnelle, d’apprentissage et de plaisir

  • Plus que le fait qu’Andrew ait parlé franchement, le vrai problème est la double posture de l’article, qui est manifestement une attaque personnelle tout en prétendant ne pas en être une
    Après avoir lu ce texte, je n’ai plus envie de construire quoi que ce soit avec Zig. Quelle que soit la décision technique prise, le BDFL à vie de Zig peut écrire ce genre de billet, et j’ai du mal à imaginer les dirigeants d’autres communautés comme Python ou Rust se comporter ainsi

    • Plus grave encore, on voit des signes que cette attitude est en train de se diffuser dans la communauté Zig. Même si ce n’est pas encore le cas de la majorité, si les personnes bienveillantes partent vers des communautés plus accueillantes, ce type de comportement pèsera davantage parmi ceux qui restent
    • Je veux défendre Andrew en disant qu’il tient sincèrement à faire ce qu’il estime juste, ce qui explique ses opinions tranchées, mais qu’il est plus patient et inclusif qu’on ne le penserait en jugeant de loin
      Certains voient dans son texte une attaque contre Bun ; moi, je peux voir dans les réactions contre Andrew une attaque personnelle. Si on met de côté les idées préconçues, il faut admettre que soit les deux camps ont tort, soit aucun n’a tort, et il faut être conscient du poids excessif que les biais personnels peuvent avoir quand on juge une situation de loin
    • S’il part sans écrire un texte trompeur qui donne une mauvaise image de Zig, et sans manquer sans prévenir les réunions prévues avec la fondation Zig, alors cela devrait aller
    • Le billet d’Andrew a été modifié plusieurs fois ; lire sa dernière révision pourrait dissiper certaines inquiétudes : https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • En Rust, il n’y a pas de BDFL par conception, et il me semble que Python a aussi quitté ce modèle. Un contributeur individuel peut certes publier un texte agressif sous le coup de la colère, mais il n’y a pas, comme pour Zig, une seule personne représentant le langage

  • J’ai envie de me ranger du côté d’Andrew. Pour avoir suivi le travail de Sumner pendant des années, les critiques de Kelley sont en grande partie vraies, même si elles sont peu aimables, et même si le résultat est utile et impressionnant, l’ensemble relevait du début à la fin davantage d’une opération d’influence à visée auto-promotionnelle
    Moi aussi je fais du développement piloté par agents huit heures par jour et je recommande à mon équipe d’utiliser Rust et Deno plutôt que Node, mais cette réécriture était mal justifiée et ressemble à la prolongation de la longue campagne de promotion menée avec succès par Dario et son entourage. Si c’était formulé plus poliment, cela aurait été mieux reçu, mais j’apprécie qu’il ait exprimé sa pensée honnête au lieu d’un texte rédigé par une équipe de communication

    • La leçon à tirer de cet épisode, c’est qu’avant de publier une réponse virulente, il faut la laisser reposer un ou deux jours et la montrer à un ami proche. Il aurait mieux valu qu’Andrew publie dès la première révision quelque chose comme la conclusion qu’il a ajoutée plus tard
    • La justification préalable de la réécriture était faible, mais on comprenait la frustration de Jarred même sans exemples
      L’explication selon laquelle Bun rencontre des difficultés spécifiques en interaction avec le garbage collector JavaScript était utile, mais Andrew n’en a absolument pas parlé. L’explication selon laquelle le nouveau code avait été validé avec la suite de tests existante a aussi dissipé le malentendu selon lequel même les tests avaient été traduits en vibe coding et n’étaient donc pas fiables. Le fait que les tests ne capturent pas tous les bugs vaut pour tous les logiciels, Zig compris
      Au fond, tout cela vient du choc entre la vision selon laquelle les langages non sûrs en mémoire entraînent un coût énorme en défauts et la réponse consistant à dire « améliorez votre niveau et n’écrivez pas de bugs », auquel se sont ajoutés le débat sur l’IA, l’implication d’Anthropic et le ton à la Linus d’Andrew, ce qui a amplifié l’affaire
    • L’idée même qu’il faudrait justifier une réécriture à des personnes extérieures à l’entreprise me paraît étrange
    • Sur les sujets techniques, je préfère une attitude à la Linus qui dit les choses telles qu’elles sont plutôt qu’un discours marketing ; les formulations de communication peuvent être réservées aux clients non techniques

  • Je me demande si Anthropic et le texte d’Andrew Kelley ont vraiment été lus de la même manière. Anthropic n’est pas une entreprise qui vend un langage de programmation, et l’article sur la réécriture de Bun en Rust contenait beaucoup de détails techniques montrant comment le produit s’était amélioré pour l’utilisateur final.
    En revanche, la réponse du camp Zig ressemble davantage à une tribune acerbe remplie d’attaques ad hominem. J’utilise Codex et je n’ai d’intérêt particulier ni dans Zig ni dans Rust, donc je regarde cela de l’extérieur.

    • Anthropic a pourtant clairement un intérêt dans le marché des langages de programmation. Si l’IA facilite les réécritures vers un langage donné, les success stories associent ce langage et l’entreprise d’IA, et le succès de Rust comme langage facile à produire avec l’IA profite aussi à Anthropic.
      De plus, lorsqu’on fait la promotion d’une réécriture réussie, on masque souvent les éléments défavorables au récit, comme la mauvaise qualité du code existant, et ici aussi des aspects importants manquaient.
      Le texte d’Andrew Kelley(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) parle des faibles standards d’ingénierie de Jarred, de ses relations extérieures défaillantes — comme son absence non signalée à des réunions avec la fondation Zig —, du tort causé par la présentation de Zig comme un mauvais choix pendant la transition vers Rust, et de la colère du ZSF qui en a résulté.
      Vu superficiellement, on peut craindre qu’un créateur de langage attaque un ancien utilisateur, mais Kelley explique pourquoi cette impression, que j’avais moi aussi en ne lisant que le texte de Bun, est injuste. Certaines attaques ad hominem sont bien réelles, et le dernier passage ajouté plus tard en parle aussi.
    • Si un studio passait de Unity à Unreal et que Unity publiait un billet attaquant la qualité du code existant et l’environnement de travail, on trouverait déjà étrange que Zig ait répondu ainsi.
    • C’est un vieux conflit entre artisanat et industrialisation. Andrew appartient à une tradition qui voudrait que tous les développeurs soient des artisans fiers de leur travail.
      Java, JavaScript, Python et C# ont dominé une industrie centrée sur le C++ en fournissant des garde-fous qui permettent même à des développeurs non perfectionnistes de travailler sans catastrophe majeure. Les gains de performance du C et du C++ étaient importants, mais ils exigeaient un haut niveau de maîtrise dans un environnement de plus en plus hostile.
      Rust et Swift ont offert une meilleure prévisibilité des performances que les langages à ramasse-miettes, avec une sécurité comparable ou supérieure, et les idées de Rust ont entraîné une explosion de nouveaux langages dans cet espace. Beaucoup relèvent toutefois davantage de l’artisanat que Rust, qui partait des besoins de l’industrie.
      Pour filer la métaphore automobile, Java, JavaScript, etc. sont des véhicules sûrs grand public, C/C++ des motos à deux roues, Rust une voiture de rallye rapide mais protectrice pour son occupant, et Zig ressemble plutôt à un quad ou à un kart à roues découvertes. Ça ne dérape pas forcément facilement, mais en cas de retournement c’est très dangereux.
      Les artisans qui ignorent les contraintes de temps et de coût estiment qu’il suffit d’avoir des développeurs prudents, mais dans l’industrie, même si l’on sait écrire du bon code, 90 % du travail se fait sous contrainte, donc il est difficile de faire confiance à son propre code comme à celui des autres. Zig a beaucoup d’atouts, mais dès le départ c’était un langage destiné à ceux qui préfèrent la liberté du bidouillage à la sécurité.
    • Les gains en taille de binaire et en vitesse n’ont pas grand-chose à voir avec la réécriture en Rust elle-même, et auraient probablement aussi été possibles en investissant des efforts comparables dans la base de code Zig. Il y a un aspect de travail additionnel visant à rendre ces chiffres plus flatteurs pour promouvoir la réécriture.
      La sécurité mémoire aussi aurait peut-être pu être atteinte de façon similaire si, au lieu de s’appuyer sur l’IA, les tests et du fuzzing de plus haut niveau, l’équipe Bun avait utilisé le fuzzer intégré recommandé par l’équipe Zig. Cela dit, pour un projet comme Bun, le Rust plus mature peut quand même être un meilleur choix.
      Le point de vue d’Andrew était essentiel pour comprendre ce qui s’était passé. Certaines formulations auraient pu être plus mesurées, mais si une mauvaise gestion est la cause directe de la dégradation des relations et de mauvais résultats d’ingénierie, le dire n’est pas une attaque personnelle, c’est du contexte nécessaire.
    • Considérer qu’un produit qui augmente la productivité des programmeurs en écrivant du code à leur place est sans rapport avec le marché des langages sous prétexte qu’il ne vend pas son propre langage est une vue à courte vue.
      D’autant plus que la direction de Zig a publiquement exprimé son aversion pour le vibe coding et critiqué l’industrie, et que le projet rejette les demandes de contribution produites avec ce type d’outil.

  • Il manque surtout de substance technique dans cette controverse. La réécriture de Bun en Rust, le texte agressif d’Andrew ou Anthropic qui vend des pelles pendant la ruée vers l’or ne m’intéressent pas tant que ça ; je voudrais voir du contenu technique concret.
    Les motivations avancées par Jarred pour le passage à Rust paraissent plausibles même si leur fondement est un peu faible, mais Andrew n’a pas expliqué en retour pourquoi ce ne serait pas le vrai problème, ni comment le résoudre proprement en Zig. J’aimerais surtout une analyse ancrée dans le vrai code Zig de Bun.

    • En ne prenant que les faits présentés par Bun, la justification technique de la réécriture reste faible, ce qui n’a rien d’étonnant puisque, dans la plupart des cas, une réécriture est une mauvaise pratique d’ingénierie.
      Bun a été lancé par quelqu’un qui avait peu d’expérience avec Zig, malgré une portée et une complexité énormes, et c’était dès le départ un projet réécrit depuis un autre langage. Si esbuild avait transposé son transpileur JavaScript·TypeScript de Go vers Zig ligne par ligne, puis jeté toute sa base de code quelques années plus tard pour la réécrire encore dans un autre langage, je me demande ce qu’il resterait à en dire.
    • Le fond de l’argument d’Andrew est que le code de Bun était mauvais dès l’origine, et il semble suggérer que Jarred est une personne toxique avec qui cette controverse ne vaut même pas la peine d’être menée.
    • Bun veut aller vite et casser des choses, alors que Zig pousse à aller lentement et avec prudence.
      Bun veut sortir au plus vite des fonctionnalités comme un shell language ou des clients SQLite/PostgreSQL, et préfère ne pas avoir à se soucier directement de la gestion mémoire. Zig oblige à gérer soi-même la mémoire et les durées de vie, et n’ajoute pas volontairement des fonctionnalités comme Drop, alors que Rust convient mieux grâce à Drop.
      De même qu’on ne construirait pas une base de données SQL en Python, Zig n’est pas l’outil adapté à Bun ; ce n’est pas tant une question de résolution idiomatique en Zig qu’une différence avec la manière dont Jarred veut faire avancer rapidement le projet.
    • Le texte original aborde ce point directement, mais en sélectionnant presque uniquement les aspects positifs. Par exemple, on y dit qu’ils ont même réécrit le compilateur Zig pour améliorer les temps de build, mais alors pourquoi ne rien dire des temps de build de Rust, généralement bien plus lents ?
    • Ceux qui vendent des pelles pendant la ruée vers l’or, ce sont les entreprises qui produisent des data centers et de l’énergie, et les tokens sont l’or.

  • Je suis d’accord avec une partie de l’avis de Kelley, mais le problème est le ton.
    Si Bun avait été réécrit de Rust vers Zig, il est peu probable qu’un membre du core team Rust publie un billet d’attaques personnelles visant Sumner tout en affirmant que ce n’en est pas. Kelley est libre d’écrire le texte qu’il veut, tout comme les gens sont libres de réagir à l’image publique de Zig produite par le BDFL d’un langage en croissance.

  • L’article sur le passage de Bun à Rust omettait une comparaison concrète des options et des chiffres sur l’impact, et traitait le résultat de manière biaisée, au point de ne pas donner l’impression d’un billet d’ingénierie
    On a eu l’impression que les gens s’intéressaient davantage à l’usage des agents qu’aux fondements techniques du portage, et sur le plan technique c’était très décevant

    • Je me demande si nous avons lu le même article. Il ne détaillait pas chaque ligne de code précise, mais contenait à plusieurs reprises des détails architecturaux profonds, des éléments sur la sûreté mémoire et les bugs, ainsi que des schémas de codage à grande échelle avec des agents

  • Il ne faut pas sous-estimer l’influence du marketing sur les dirigeants et les cadres, ni à quel point les personnes qui accèdent à des postes comme CEO peuvent être influencées par des émotions très triviales
    Le simple fait que ce soit une occasion de promouvoir le nouveau modèle Fable, ajouté au fait que Zig s’oppose publiquement à l’usage des produits Anthropic, a peut-être suffi à faire du réécriture de Bun en Rust une décision pratiquement déjà prise

    • Je ne vois pas pourquoi penser que la direction est intervenue d’une manière ou d’une autre. Il est bien plus plausible que Jarred ait simplement fait ce qu’il voulait faire, et c’est d’ailleurs ce qu’il a toujours dit

  • Je ne comprends pas pourquoi, dans un débat sur le changement de langage, on en vient à parler des attentes en matière d’horaires de travail. Même s’il était un mauvais manager, cela donne l’impression de chercher artificiellement des angles négatifs
    Le fait que le camp Zig se concentre à peine sur les avantages techniques de la réécriture est aussi révélateur. Anthropic a mis en avant plusieurs améliorations, mais il est difficile de trouver ne serait-ce qu’une tentative de les réfuter
    Si réécrire mon projet avec un grand modèle de langage produisait comme résultat une amélioration sans inconvénients, cela m’inquiéterait énormément et je réagirais en conséquence ; ici, à la place, on parle bizarrement des horaires de travail

  • Il existe un conflit d’intérêts évident entre un projet détenu par Anthropic et la direction d’une communauté de langage ouvertement hostile au code généré par l’IA
    Andrew Kelley aurait mieux fait de se contenter de dire cela et d’en rester là ; ses jugements sur l’énergie et les motivations du fondateur de Bun n’apportent presque rien

    • Il est difficile pour les partisans absolus de l’IA comme pour ses opposants absolus de trouver un compromis. Les arguments techniques et la plupart des attaques relèvent surtout de rationalisations a posteriori ; chaque organisation a simplement son propre contexte et ses propres objectifs
      Kelley le savait aussi, mais il semble ne pas avoir résisté à la tentation de brouiller le propos essentiel. Le texte virulent ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) allait trop loin, mais l’appendice appelant à aller de l’avant est sain. Mieux vaut, selon moi, un BDFL un peu piquant que trop fade.