Mon point de vue sur la réécriture de Bun en Rust

• Andrew Kelley, créateur de Zig, interprète la réécriture de Bun en Rust moins comme une question de victoire ou défaite des fonctionnalités d’un langage que comme un épisode révélant la rupture de la relation entre la Zig Software Foundation (ZSF) et Bun/Oven
• Au départ, Bun reconnaissait Zig comme la base de ses performances et versait à la ZSF un don annuel de 60 000 $, mais après être devenu une startup financée par le capital-risque, le mécontentement a grandi autour du fonctionnement de l’organisation et de la qualité du code
• La ZSF s’inquiétait dans le codebase de Bun de solutions bricolées, d’un usage abusif des assertions, et d’un manque de temps consacré aux bugs et à la dette technique par rapport au rythme d’ajout de fonctionnalités ; elle voyait aussi d’un mauvais œil le fait que Bun puisse apparaître comme un cas représentatif de Zig
• Kelley critique le billet sur le passage de Bun à Rust pour avoir présenté la réduction des bugs comme une opposition entre guide de style et fonctionnalités du langage, alors que, selon lui, l’essentiel tient au temps d’ingénierie investi pour éliminer les bugs et à la gestion de la qualité du code
• La ZSF dit être reconnaissante pour les dons de Bun, mais considère que les dons comme la relation ont pris fin après le rachat par Anthropic, et accueille positivement le fait que la réécriture en Rust sépare désormais les intérêts commerciaux de Bun et de Zig

---

Les débuts de la relation entre Bun et Zig

• Jarred a rejoint la communauté Zig il y a environ 5 ans, et Kelley le voyait comme quelqu’un avec une forte « beginner energy », qui essaie vite et apprend beaucoup
• À mesure que Bun attirait l’attention comme toolchain JavaScript, Zig a lui aussi commencé à susciter davantage d’intérêt
• Kelley pense que Jarred aurait probablement pu obtenir, rien qu’avec le financement participatif, un revenu stable à l’échelle de San Francisco, mais estime qu’il a adopté une logique à la Thiel Fellowship et une approche typiquement Silicon Valley en choisissant le capital-risque
• À ses débuts, Bun était favorable au projet Zig
  • Le site web de Bun créditait Zig pour ses performances
  • Un don mensuel équivalant à 60 000 $ par an était mis en place pour la Zig Software Foundation
  • Kelley estime aussi que les remerciements adressés au projet Zig dans le billet sur la réécriture de Bun en Rust semblent sincères

Les tensions après le passage au statut de startup financée par VC

• Une fois Bun devenu une startup financée par VC, Jarred s’est éloigné de la figure du développeur qui fait grandir un projet open source avec sa communauté pour devenir davantage un dirigeant d’entreprise
• Les messages de recrutement d’Oven annonçaient une charge de travail intense pendant environ les 9 premiers mois et précisaient que si le work-life balance signifiait « beaucoup de temps hors travail », le poste ne conviendrait peut-être pas
• Kelley dit avoir entendu de manière répétée, en parlant avec des candidats et des employés d’Oven, des retours négatifs sur le rôle de Jarred comme manager
  • Les problèmes évoqués incluaient un manque de communication, des attentes irréalistes, peu d’empathie et un manque d’expérience
• En conséquence, des membres de la communauté qui voulaient travailler avec Zig ont fini par éviter Oven et Bun
• Plus Jarred se concentrait sur la productivité et une stratégie de sortie de startup, plus il s’éloignait de la vision de long terme de Kelley pour Zig
  • Par exemple, Jarred demandait de prioriser l’implémentation du Language Server Protocol et l’intégration à VSCode, alors que Kelley avait un plan plus vaste en tête

Les problèmes de qualité de code que la ZSF voyait chez Bun

• Pour Kelley, le problème central est la qualité du code
• L’équipe Zig lit le code source des projets utilisateurs, vérifie l’impact des changements du langage sur les utilisateurs et teste les régressions de casse et de performance provoquées par ces changements
• Dans le codebase de Bun, les pratiques de programmation qui inquiétaient la ZSF se seraient multipliées
  • accumulation continue d’implémentations bricolées
  • usage abusif des assertions
  • peu de temps consacré à la réflexion, à l’élimination des bugs et à la réduction de la dette technique par rapport à la vitesse d’ajout des fonctionnalités
• Kelley craignait que cette manière de faire chez Bun se combine avec les critiques sur la sécurité mémoire de Zig, et souhaitait prendre ses distances socialement avec le projet Bun
• La ZSF a essayé d’orienter Bun vers de meilleures pratiques de programmation, sans succès

Le rachat par Anthropic et la réécriture en Rust

• Au sein de la ZSF, l’idée s’est installée que Bun relevait presque de la charge nette (net liability)
• Le fait que Bun puisse apparaître comme un exemple représentatif de Zig était perçu comme problématique, alors qu’en pratique il s’agissait plutôt d’un exemple de « ce qu’il ne faut pas faire en code Zig »
• Kelley dit avoir toujours trouvé fragile le projet commercial de Bun, résumé selon lui à « vendre un truc cloud », et estimait qu’en cas de revente future, Zig risquerait aussi d’en subir indirectement une publicité négative
• Après le rachat par Anthropic, la ZSF s’est sentie soulagée
  • les dons se sont arrêtés discrètement, ce à quoi la ZSF s’attendait
  • l’équipe Bun n’a ni annulé ni honoré les réunions mensuelles, et la relation a été considérée comme terminée
• La ZSF soupçonnait qu’une réécriture en Rust allait arriver dans les jours suivants, et s’en est réjouie
• Après le rachat par Anthropic, le simple lien indirect entre Claude écrit avec Bun, et Bun écrit avec Zig, a aussi créé une gêne dans la communauté Zig
  • hausse des drive-by slop contributions
  • afflux d’enthousiastes de l’IA collant des sorties de LLM dans les messages du forum
  • Kelley craint que Zig soit connu comme un langage de programmation associé à l’IA
• Quand Jarred a annoncé la réécriture en Rust, Kelley dit l’avoir très bien accueillie, avec le sentiment que « ce n’est plus mon problème »

Réponse critique au billet de Bun sur la réécriture en Rust

• Kelley estime que le billet de Bun sur sa réécriture en Rust est bien écrit, tout en pointant plusieurs problèmes de fond

• Le cœur de la réduction des bugs

  • Le billet de Bun présente les choses comme s’il fallait choisir entre un guide de style et les fonctionnalités d’un langage pour éviter les bugs
  • Pour Kelley, le principal moyen de supprimer les bugs consiste à consacrer des ressources d’ingénierie à les trouver puis à les éliminer
  • Selon lui, TigerBeetle a pris ce temps pour trouver et corriger les bugs tout en gardant une relation saine avec la ZSF, alors que Bun n’a fait ni l’un ni l’autre

• Contradiction autour de la suite de tests

  • Kelley considère que le billet de Bun invoque une suite de tests suffisante pour justifier le déploiement d’un million de lignes de code non relues
  • Il rétorque alors que si c’est le cas, pourquoi le code Zig avait-il tant de bugs agaçants, et pourquoi la suite de tests ne pouvait-elle pas attraper les bugs du code Zig tout en attrapant ceux d’un million de lignes de code non relues ?

• Performances et LTO

  • Le billet de Bun attribue les gains de performance au LTO, mais Kelley affirme que Zig a pris en charge le LTO pendant toute l’existence de Bun
  • Zig avait autrefois activé le LTO par défaut, mais l’a retiré à cause d’un trop grand nombre de bugs LLVM, qui affecteraient aussi Rust
  • Kelley pense qu’il est très probable que la ZSF ait recommandé d’activer le LTO et que Bun n’en ait rien fait

• fuzzing

  • Le billet de Bun laisse entendre qu’un travail sérieux de fuzzing avait été réalisé sur le code Zig, mais Kelley affirme que l’équipe Bun lui a dit en appel qu’elle ne faisait aucun fuzzing

• Taille du binaire et comptime

  • Le billet de Bun présente plusieurs travaux d’ingénierie pour réduire la taille du binaire comme des arguments en faveur de la réécriture en Rust, mais Kelley estime que ces travaux n’ont rien à voir avec la réécriture elle-même
  • Il s’agit plutôt, selon lui, de travaux d’ingénierie qui auraient dû être menés dès le départ dans le codebase Zig
  • La ZSF avertissait depuis des années Bun de l’usage abusif de comptime et a même créé une fonction de rapport temporel permettant d’auditer l’usage de comptime/inline et les temps de compilation

• Vitesse de compilation

  • Kelley souligne que le billet de Bun ne mentionnait pas la vitesse de compilation
  • Le projet du compilateur Zig représente environ 600 000 lignes, soit une taille comparable à celle de Bun avant sa réécriture
  • D’après ses mesures, une compilation complète depuis zéro avec un cache vide prend 16 secondes, et chaque modification suivante après activation de la compilation incrémentale prend 90 ms
  • Il demande quelles sont les mesures équivalentes pour Bun après la réécriture en Rust

La conclusion de Kelley

• Pour Kelley, le vrai problème n’est pas les fonctionnalités du langage de programmation, mais la rupture de la relation
• La ZSF se dit sincèrement reconnaissante pour les dons reçus de Bun et explique que cet argent a servi à la rémunération des contributeurs Zig
• Kelley précise qu’il ne cherche pas à attaquer Jarred de manière malveillante
  • Jarred a des goûts et des objectifs de vie différents des siens, mais il estime qu’il a réussi à construire la vie qu’il voulait
  • Il dit accepter que Jarred soit heureux et ait du succès, sans animosité de sa part
• Kelley se réjouit toutefois que les intérêts commerciaux de la ZSF et de Bun ne soient désormais plus imbriqués
• Il estime qu’une fois terminée la controverse publique sur le bien-fondé ou non de la réécriture en Rust comme critère de choix d’un langage, les interactions entre les deux camps cesseront elles aussi

[click]

En lisant l’article, ça me donne envie de n’utiliser ni Zig ni Bun.

[GN⁺]

Commentaires sur Hacker News

• J’ai énormément appris en lisant le code d’Andrew et, comme il l’a dit dans le texte original, Bun n’aurait pas existé sans Zig
  Concernant le passage affirmant : « L’article prétend qu’ils ont fuzzé le code Zig, mais lors de l’appel, toute l’équipe de Bun a dit qu’elle ne fuzzait rien du tout. Ça ressemble à une manipulation flagrante », il existe une PR d’intégration de Fuzzilli : https://github.com/oven-sh/bun/pull/24826
  Il existe aussi des PR fusionnées qui corrigent des problèmes trouvés par Fuzzilli dans le code Zig de Bun : https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
  En cherchant « Fuzzilli », on trouve encore plus de PR : https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...

  • Ce qu’Andrew voulait probablement dire, c’était zig build test --fuzz, c’est-à-dire le fuzzer intégré de Zig ; c’est sans doute l’outil qui entrait dans son périmètre
  • Je ne comprends pas bien. En quoi le fait d’avoir « fuzzé le code Zig » est-il lié à l’ajout de l’intégration de Fuzzilli dans Bun ?
  • Je ne prends pas vraiment parti dans cette dispute, mais relever un seul détail précis dans le billet d’Andrew sans aborder le reste me paraît un peu vain
    Je ne voue un culte ni à l’un ni à l’autre ; j’essaie juste de comprendre, parce qu’on dirait que toute la discussion se dégrade au lieu d’aller dans une meilleure direction
  • Les liens montrent qu’un fuzzer a été utilisé, mais ne répondent pas à l’autre moitié de l’affirmation d’Andrew. Est-ce qu’Andrew a mal rapporté ou mal mémorisé le contenu de l’appel ?
    Le fait d’être bas-voté pour avoir posé une question de vérification factuelle est assez révélateur. Il y a peut-être une réponse simple du genre « ils n’utilisaient pas de fuzzer jusqu’à récemment, donc les deux ont raison », mais je n’en sais rien, c’est juste pour ça que je demande

• Cet article est peu professionnel et embarrassant pour Zig
  Je ne sais presque rien de Jarred, mais le texte que j’ai lu hier donnait l’impression qu’il était reconnaissant envers Zig, et je découvre maintenant qu’il a aussi fait un don assez important à Zig
  Tout cet article l’attaque publiquement et personnellement simplement parce qu’il a choisi un autre produit
  Si Andrew pense que ce billet va réhabiliter Zig, c’est étrange ; en réalité, il ne fait que donner une image puérile. À moins qu’il ne veuille simplement s’en prendre à Jarred

  • Je ne vois pas en quoi exprimer sur son blog personnel une opinion personnelle honnête sur un sujet qui lui tient à cœur serait non professionnel
    Tout le monde doit-il devenir une marque ambulante, filtrer en permanence ses propos, marcher sur des œufs et se cacher derrière un langage d’entreprise pour avoir l’air « professionnel » ?
    Le monde a besoin de plus de franchise, pas de moins, et les interactions en ligne semblent de moins en moins authentiques
  • Oui. C’est pour ça qu’Anthropic et Bun se sont éloignés de Zig
    Zig est en pratique presque un projet porté par une seule personne, et cette personne prend des décisions de plus en plus instables
    Bien sûr, c’est son projet et il en a le droit, mais si vous êtes une entreprise valorisée à près d’un trillion, vous n’avez probablement pas envie d’assumer ce risque de supply chain
    Du point de vue d’Anthropic, mieux vaut couper court plutôt que d’investir davantage dans l’écosystème Zig, à partir du moment où il devient clair qu’un not-so-BDFL risque de dépasser les bornes
  • Antirez a écrit un billet qui disait en substance qu’il est absurde de ne pas utiliser l’IA pour augmenter la couverture de test
    À l’inverse, au vu de son niveau d’adoption et du temps de développement, la couverture de test de Zig est embarrassante de faiblesse
    L’attitude de Zig vis-à-vis de l’IA est complètement puérile. Alors qu’ils pourraient en tirer énormément, ils refusent même d’examiner la moindre possibilité d’usage
    Vouloir éviter le spam de PR est une chose ; se lier les mains et ne pas utiliser du tout l’IA, même en interne sur les cas les plus simples et les plus rentables, en est une autre
    On pourrait aussi utiliser l’IA pour trier, dans le spam de PR, les candidats à de vrais bugs, mais comme ils refusent toute aide, de vrais bugs restent en attente plus longtemps que nécessaire
  • Le texte semble au contraire se réjouir du passage à Rust. Ce point est répété plusieurs fois dans le billet, au point de donner l’impression qu’il attendait et espérait que Bun quitte Zig
  • D’accord. Ce texte aurait dû se concentrer sur des faits froids au lieu d’aligner des critiques personnelles qu’on pourrait difficilement écrire dans un document de travail
    Malheureusement, beaucoup trop de développeurs open source sont bien trop à l’aise avec cette manière d’écrire, et c’est l’une des raisons pour lesquelles j’ai arrêté de contribuer à l’open source
    Dans une entreprise raisonnable, se comporter ainsi vaudrait un licenciement ou au minimum une sanction disciplinaire

• La phrase « il n’y a aucune critique personnelle envers Jarred » est assez forte à placer à la fin d’un texte qui ressemble presque entièrement à une critique personnelle à peine voilée
  Dire que quelqu’un dégage une énergie de débutant en l’enrobant d’un faux positif du genre « quelqu’un qui échoue et apprend », ou écrire que, d’après la rumeur, on l’appelle un « manager qui pue », c’est de cet ordre-là
  C’est assez proche de « je ne dis pas que cette personne est mauvaise, mais je vais écrire sur mon blog que tout le monde s’accorde à dire qu’elle l’est », et même si c’était vrai, ça paraît de très mauvais goût

  • Je ne sais pas si qualifier quelqu’un de « manager qui pue » relève d’une attaque personnelle. C’est amusant de voir qu’on n’arrive pas à distinguer la personne de son « travail »
    Moi aussi, j’ai travaillé avec des managers lamentables, mais je ne leur en veux pas personnellement
  • Il y a ce genre d’attaques ad hominem dans le reste du texte, donc dire ensuite « il n’y a pas de critique personnelle » manque de cohérence
    « Le réseau de rumeurs était vaste et en bonne santé, rempli de raisins juteux, et tout leur jus portait le même message : Jarred était un manager qui puait »
    « Jarred écrivait déjà des textes merdiques avant même d’utiliser des LLM »
    C’est un texte d’une puérilité étrange. J’aime bien les billets qui laissent tomber le filtre corporate et disent le fond de la pensée, mais ce genre de texte montre aussi comment la personne pense et agit
    Avec un bon leadership, même sans filtre corporate, le résultat reste professionnel ; ici, cela révèle quelque chose de bien inférieur
  • Donc l’énergie de débutant serait une mauvaise chose ? Sur des side projects, j’aime l’énergie de débutant. On échoue et on apprend
    Quand il n’y a ni enjeu de sécurité ni personnes dépendantes, c’est tout à fait normal. Ce n’est simplement pas la même chose que le management

• Le passage indiquant que la ZSF a poussé un soupir de soulagement une fois le rachat par Anthropic terminé m’a marqué. Cela veut dire que même quand les dons se sont discrètement arrêtés, le compte était prêt, et qu’ils n’ont pas été surpris non plus quand les réunions mensuelles n’étaient ni annulées ni honorées. La relation était déjà terminée
  J’ai vu ce genre de chose plusieurs fois. Quand un projet ou une organisation est racheté, le « bien » qu’ils faisaient ne s’arrête pas dans le fracas ; ça disparaît simplement quand le sponsor commence à les ignorer en silence
  Heureusement qu’ils ont su lire les signes et se préparer. C’est une excellente leçon qu’on n’a pas besoin d’apprendre dans la douleur, et les projets libres et open source dépendants d’un ou deux gros donateurs devraient faire attention
  Je pense qu’on va voir ce genre de situation bien plus souvent dans l’écosystème des outils de développement

• Il y a ailleurs dans ce fil des réactions tranchantes sur le ton du billet, mais ce texte a vraiment cassé mon enthousiasme pour Zig
  Le drama est divertissant, et la sincérité d’Andrew est peut-être respectable, mais ce n’est pas le professionnalisme qu’on attend d’un projet sérieux
  Même si cela paraît ennuyeux et peu inspirant, c’est ce genre de stabilité que je veux d’une stack technique et de sa gouvernance
  Jarred était peut-être un passif net, mais Bun était un très gros projet en Zig, et voir ce projet partir n’est pas aussi bénéfique pour Zig qu’Andrew semble le dire
  Il donne l’impression d’accorder une priorité bien plus élevée à la pureté et à l’idéologie qu’à la croissance du langage. Pour un langage de programmation sérieux, l’adoption et la masse critique comptent aussi

  • Je ne vois pas immédiatement le lien entre le sérieux d’un projet et les formulations choisies par son auteur sur son blog personnel
    C’est un peu comme dire que Linux ne pouvait pas devenir un projet sérieux à cause du ton des e-mails de Linus
  • Je comprends qu’il soit en colère. On dirait qu’on lui reproche surtout d’éprouver des émotions et d’en laisser transparaître les signaux
    En plus, il n’a même pas écrit cela dans un cadre officiel, mais sur son blog personnel
  • Je ne vois pas en quoi ce texte démontre de manière convaincante qu’Andrew Kelley manquerait du professionnalisme nécessaire pour piloter un projet sérieux comme Zig
    L’important, ce n’est pas ce qu’il a apporté au langage ?
  • C’est proche du contre-argument central, mais ça le manque légèrement. C’est la collision entre la culture hacker traditionnelle et le raisonnement VC de growth hacking
    Pourquoi l’adoption et la masse critique devraient-elles forcément être importantes ? Pourquoi ne pourrait-on pas créer un langage conforme à la pureté et à l’idéologie qu’on recherche, même au prix d’une adoption plus large ?
    Pourquoi tout devrait-il être optimisé pour la croissance du nombre d’utilisateurs et de la notoriété ?
  • Dans ce cas, Bun a été racheté par Anthropic. On ne peut pas forcément en déduire que son départ de Zig repose sur des mérites techniques
    Même s’ils prétendent le contraire

• Ce texte m’a paru très rafraîchissant. Il aurait été tentant de répondre de façon plus raffinée au langage façon RP du billet de Bun, mais il ne l’a pas fait
  Il aurait pu inclure des faits donnant une mauvaise image de Jarred tout en cachant prudemment sa propre opinion, par exemple avec un truc du style : « J’ai entendu dire que des gens l’appelaient un manager qui pue. Ce n’est pas moi qui le dis, ce sont les autres. » Mais non, il a juste été franc, et j’ai apprécié

  • Le fait que l’auteur ne cherche pas à cacher sa personnalité et ses opinions est rafraîchissant
    En revanche, le contenu de cette personnalité et de ces opinions est assez difficile à accepter
  • On dirait simplement une longue attaque ad hominem
  • D’accord. Ce billet de blog donne l’impression d’un équilibre entre le ton RP et x.com

• Comme la première et plus grosse partie du texte est consacrée à des attaques ad hominem spéculatives, j’ai du mal à accorder du crédit à ce que dit l’auteur
  C’était une bonne occasion de résumer les points forts de Zig. Les textes évangélisateurs et inspirants de mitchellh m’avaient récemment donné envie d’apprendre Zig, mais ce billet m’a coupé cette envie

  • Tu n’as peut-être pas été le seul à le ressentir. Peux-tu citer textuellement les passages précis qui t’ont donné cette impression d’« attaques ad hominem spéculatives » ?
    On voit assez bien ce qu’Andrew pense de Jarred, de sa manière de travailler et de son attitude professionnelle, mais je ne vois pas clairement ce qui relèverait de l’attaque personnelle, de la spéculation, ou non
  • Le problème, c’est que l’auteur en question est le créateur de Zig

• Les attaques personnelles contre Jarred ne semblent pas vraiment aider l’argument en faveur de l’usage de Zig
  Il aurait fallu se concentrer sur le langage au lieu d’utiliser des expressions comme « gestionnaire nauséabond »
  Honnêtement, en lisant ce texte, j’ai autant envie d’éviter Andrew que Jarred

  • Il ne s’agit pas d’une critique de Jarred en tant qu’individu, mais de son comportement public non professionnel
    C’est aussi quelque chose que beaucoup de gens dans la communauté ont vu ces derniers mois
    Dire que « Jarred, dans son rôle professionnel, a poussé de nombreuses personnes hors de notre communauté, et nous voulons garder nos distances » ne signifie pas « Jarred est une mauvaise personne dans le privé »
    Bien sûr, dans ce milieu, vu ce que les VC laissent comme vie privée en dehors du travail, cela peut presque être compris comme la même chose, mais ce n’est pas le problème d’Andrew
    Je ne défends pas le style d’Andrew. Il aurait peut-être pu un peu plus masquer sa neurodiversité en s’adressant à un lectorat neurotypique plus large
    Cela dit, c’est son projet, sa communauté connaît déjà ce trait, et c’est aussi une donnée connue
    Au lieu de lui prêter le sous-entendu secondaire « Andrew essaie d’assassiner la réputation de Jarred », il peut être utile de relire le texte en partant du principe qu’Andrew est totalement sincère
  • Le comportement social d’Andrew en ligne ressemble globalement à une succession de mesquinerie
    Ce n’est même pas la première fois que je vois un texte qui m’a semblé ouvertement malveillant. On est bien au-delà de ce qu’on pourrait pudiquement appeler « franc-parler »
    « Le silence n’était pas une option ? »

• Contrairement à l’affirmation « il n’y a pas de critique personnelle contre Jarred », l’ensemble du texte m’a donné l’impression d’être une critique personnelle de Jarred

  • J’y vois plutôt une critique professionnelle de Jarred. Même si cela se focalise sur une personne, je ne pense pas que ce soit quelque chose de très privé
  • Littéralement trois phrases plus loin, il l’insulte de nouveau avec « rêve fiévreux de fantasme de productivité »
    Même si c’était vrai, le publier sous cette forme n’était pas judicieux. Si l’objectif était de défendre Zig, il y avait moyen de le faire d’une manière moins personnelle
  • Cette partie semble mal écrite et passive-agressive, mais il avait probablement peur que les anges d’Internet s’indignent parce qu’il avait été impoli envers Jarred

• Toute cette opération consistant à réécrire Bun de Zig vers Rust ressemble à un grand coup marketing
  Si Anthropic AI est vraiment aussi puissant, pourquoi ne pas lui confier un travail plus ambitieux consistant à corriger les bugs et à repenser la base de code Zig existante de Bun, afin d’éviter non seulement les bugs actuels mais aussi l’apparition de bugs similaires à l’avenir ?

  • La seule raison de cette réécriture est que le créateur de Zig a annoncé qu’il n’accepterait pas de contributions IA
    C’est cela qui a froissé Anthropic
  • Je me demande si ce mouvement étrange vient d’Anthropic, ou d’un fondateur surexcité qui essayait de mieux vendre l’histoire même après que l’accord avait été conclu
    On peut imaginer qu’Anthropic aurait pu vouloir acquérir Bun même sans cette mise en scène
  • Il est intéressant de noter qu’avant la réécriture en Rust, Bun maintenait un fork destiné à accélérer la compilation et disait aux personnes qui posaient la question que ce fork ne pourrait jamais être fusionné à cause de la politique anti-LLM de Zig
    Quelques semaines plus tard, Bun a commencé la réécriture en Rust. Ce n’est pas explicite, mais je pense que les deux événements peuvent être liés
  • Rust est précisément l’outil qui offre gratuitement aux humains comme aux LLM une bonne partie de ces vérifications, ainsi que des mécanismes comme RAII
  • Au final, soit Claude n’est pas capable de corriger ces bugs, soit il le peut mais l’équipe de Bun a délibérément choisi de ne pas les corriger
    Je ne sais pas laquelle des deux options est la pire