La réécriture expérimentale de Bun en Rust atteint 99,8 % de compatibilité avec les tests sur Linux x64 glibc

• La réécriture de Bun en Rust réussit 99,8 % de la suite de tests existante dans un environnement Linux x64 glibc
• Le codebase est « essentiellement le même codebase », et le passage à Rust permet au compilateur d’imposer le cycle de vie des types et d’utiliser des destructeurs au moment nécessaire
• Les parties non sûres deviennent plus explicites avec unsafe en Rust, ce qui a pour effet d’encourager le refactoring
• La raison de cette réécriture est la fatigue à passer beaucoup de temps à s’inquiéter des fuites mémoire, des crashs et des problèmes de stabilité, puis à les corriger, avec la volonté d’avoir un langage offrant des outils plus puissants pour empêcher cela
• L’ampleur totale est décrite comme une réécriture de 960 000 LOC, et après avoir fait passer la suite de tests sur Linux, les autres plateformes devraient suivre bientôt

---

État de la réécriture en Rust

• La réécriture de Bun en Rust réussit 99,8 % de la suite de tests existante dans un environnement Linux x64 glibc
• Le codebase est « essentiellement le même codebase », et en le basculant vers Rust, le compilateur peut imposer le cycle de vie des types et utiliser des destructeurs au moment nécessaire
• Les parties non sûres apparaissent plus clairement sous la forme de unsafe en Rust, ce qui a pour effet d’encourager le refactoring
• Cette réécriture s’explique notamment par la lassitude à consacrer beaucoup de temps à s’inquiéter des fuites mémoire, des crashs et des problèmes de stabilité, puis à les corriger, ainsi que par le souhait qu’un langage fournisse des outils plus puissants pour éviter ce type de problèmes
• L’ampleur totale est décrite comme une réécriture de 960 000 LOC, et le code fonctionne réellement, passe la suite de tests sur Linux, tandis que les autres plateformes devraient être visées prochainement

Contenu à venir et réponses sur la compilation

• La signification de cette évolution pour Bun, les benchmarks, l’utilisation mémoire, la maintenabilité à venir et le processus concret de réécriture seront traités dans un billet de blog séparé
• Le processus de réécriture ne s’est pas résumé à dire simplement « claude, rewrite bun in rust. make no mistakes », et le travail pour arriver à un état pleinement fonctionnel a commencé il y a 6 jours
• Il est indiqué que cela aurait représenté une quantité de travail énorme si tout avait été fait manuellement
• Le temps de compilation est globalement similaire à celui de la version Zig existante, qui utilise le compilateur Zig plus rapide, et il est précisé qu’avec le compilateur Zig upstream, le port Rust se serait compilé plus vite
• Les performances seront abordées dans un billet de blog séparé
• À propos de l’étape suivante consistant à remplacer libc elle-même par sa version Rust, frankenlibc, il est indiqué qu’avant cela, il compte créer sa propre libc

[GN⁺]

Commentaires sur Hacker News

• Il y a eu un message sur le même sujet il y a 4 jours : https://news.ycombinator.com/item?id=48019226
  Un contributeur de Bun a dit qu’il s’agissait de sa branche personnelle, que le fil de l’époque était une surréaction à du code non fonctionnel, qu’aucune décision n’avait encore été prise sur une réécriture, et qu’il y avait de fortes chances que tout le code soit jeté
  Il disait vouloir comparer la version Rust et la version Zig côte à côte pour voir à quoi ressemble une version fonctionnelle, comment se situent les performances et la maintenabilité, et à quel point il est difficile de faire passer la suite de tests de Bun

  • Au moment où il a écrit ce message, cargo check remontait plus de 16 000 erreurs du compilateur, et il n’était même pas possible d’afficher le numéro de version ni d’exécuter du JavaScript
    Il ne s’attendait pas à ce que ça fonctionne aussi vite, ni à ce que les performances soient aussi compétitives, et il a indiqué qu’un billet de blog plus détaillé était prévu
  • Ils ont l’air d’avoir pris leur décision après avoir évalué la maintenabilité, les performances et les vérifications via la suite de tests
  • Donc, jusqu’ici, cela signifie que c’est une expérience très réussie
  • Il y a quelques jours, il disait aussi : « l’open source va sans doute partir dans la direction opposée. Contributions humaines interdites. Le slop sera une relique nostalgique de 2025~2026 »
    Après le rachat par Anthropic, on aurait dû s’y attendre, mais c’est quand même décevant. Je ne suis pas opposé à la technologie des grands modèles de langage en elle-même, mais la manière dont ces entreprises d’“IA” ont avalé l’industrie du logiciel et la société dans son ensemble pour accumuler du pouvoir est répugnante, et crée une dépendance très malsaine
    Il faut anticiper de plusieurs coups et préparer une stack logicielle et des communautés sans slop. Cela inclut Zig et son écosystème. Même si nous et les générations futures ne pourrons peut-être pas vivre entièrement sans slop, il est plus important que jamais de garantir une culture informatique durable, fondée sur la liberté comme liberté

• C’est très impressionnant d’avoir fait ça aussi vite. Je travaille depuis 5 mois sur un projet similaire de portage de TypeScript vers Rust, mais sans Mythos ni accès illimité aux tokens
  Malgré ça, on est presque à 100 % de réussite, et au moment où j’écris on est à 99,6 % : https://tsz.dev
  Rust est particulièrement bien adapté à l’écriture de code avec des grands modèles de langage. Grâce à son système de types strict, on évite davantage d’erreurs complètement stupides qu’un autre langage pourrait laisser passer
  Cela dit, écrire du code avec des grands modèles de langage ne supprime pas le besoin d’une vision d’architecture ni du jugement nécessaire pour arbitrer les trade-offs d’un projet. C’est pourquoi Jarred et son équipe sont les bonnes personnes pour exploiter d’énormes volumes de code produits avec des grands modèles de langage

  • Le fait que Rust impose des invariants à la compilation aide les grands modèles de langage à produire du code fonctionnel, parce qu’ils reçoivent un feedback rapide et peuvent revenir en arrière
    En revanche, Rust est un langage complexe, donc de petits changements peuvent facilement déclencher une avalanche de refactorings dans du code éloigné. Si l’architecture initiale est mauvaise ou insuffisante, il y a un fort risque qu’en faisant grossir progressivement la base de code comme les grands modèles de langage ont tendance à le faire, on se retrouve avec un plat de spaghettis
    Au final, je crains qu’on obtienne des programmes qui compilent et s’exécutent, mais que les humains ne peuvent ni lire ni maintenir
  • Je fais aussi quelque chose de similaire avec Postgres multithread. En 1 mois, j’ai atteint 96 % de réussite sur les tests de régression de pg, et on est arrivé à 823K LOC
    Tout ce que j’avais, c’était 8 comptes Codex à 200 $/mois, sans Mythos
    J’ai aussi vu ici les avantages de Rust, et avec mon expérience de Postgres, je pense pouvoir prendre de bonnes décisions de conception sur plusieurs aspects avec lesquels les gens ont longtemps eu du mal dans pg. Je suis enthousiaste à l’idée que l’IA rende plus réalisables des améliorations de logiciels complexes qui ne l’étaient pas auparavant
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Quand Microsoft a réécrit cela en Go, l’un des leads a expliqué qu’ils avaient choisi Go plutôt que Rust en raison de la similarité de paradigme. Le garbage collection, entre autres, était similaire, et selon lui Rust aurait été plus difficile et aurait demandé davantage de contournements ; je serais curieux d’avoir l’avis de quelqu’un qui l’a fait en pratique
  • Rust est excellent, mais dans les gros projets, essayer de produire du logiciel Rust avec des grands modèles de langage fait s’effondrer la manière de travailler qu’on voudrait avoir
    Même maintenir ou établir des frontières propres cesse d’être un état de flow pour devenir une revue pénible, et à la fin on bascule en mode procrastination
  • J’ai eu du mal à empêcher Opus d’ignorer les idiomes Rust et d’écrire le Rust le plus bizarre possible. Si quelqu’un a des conseils, je suis preneur

• Je n’ai pas de justification très solide, mais je n’ai plus envie d’être associé à Bun. C’est surtout instinctif, mais je n’arrive plus à lui faire confiance ni à le soutenir
  Ils ont forké Zig pour exploiter des réécritures par LLM, et ont construit des choses comme une compilation non déterministe que l’équipe Zig ne voulait clairement pas
  Maintenant ils font une réécriture en Rust par LLM en se plaignant. Il est tout à fait possible que ce soit justement la philosophie de conception de Zig, avec ses choix difficiles mais précis, qui les ait amenés là où ils sont, et qu’une réécriture en Rust marque réellement le début du déclin
  C’est un jugement plus politique que technique, mais Bun donne l’impression d’être entièrement porté par Claude. Je ne serais même pas surpris que le prochain slogan marketing d’Anthropic soit : “Claude Mythos réécrit en Rust un runtime JS leader de 950K LOC”

  • Je ne sais pas si c’est le développeur qui écrit du code dans son propre dépôt qui est un bébé pleurnichard, ou si c’est la personne sur Hacker News qui s’en plaint
  • Je n’ai pas vu Jarred se plaindre, donc j’ai l’impression que cette émotion est mal dirigée
    Le fil Twitter lié expose des justifications techniques claires
  • Je ne suis pas personnellement si investi dans Bun, mais je ne vois pas pourquoi ce serait important. Je me demande si les gens examinent aussi leurs autres dépendances de cette façon
    Travailler dans l’écosystème JS/NPM repose déjà largement sur un pur acte de foi envers des dépendances non vérifiées, et je ne vois pas en quoi l’avant/après réécriture par LLM changerait grand-chose. Si les objectifs initiaux et le contrat d’API sont respectés, quelle différence ? Je doute même que les gens lisaient attentivement le code source d’origine
  • Je suis d’accord. Bun a toujours eu une philosophie de conception très claire. Faire tout ce qu’il veut : runtime, bundler, suite de tests, gestionnaire de paquets, et sortir des patchs cassés chaque semaine
    C’était toujours présenté comme une manière d’écraser les concurrents existants en étant meilleur, plus rapide et plus fort, mais il était évident qu’ils n’allaient jamais appliquer Keep It Simple Stupid
    Il était aussi évident que, dans un avenir proche, on ne verrait ça en production réelle que chez des startups YC qui s’embrasent une par une comme si on avait jeté de l’accélérant dessus. On dirait que le point de non-retour a désormais été dépassé
  • Bun est pratiquement mort
    Anthropic a acheté Bun dans une tentative assez stupide de résoudre ses propres problèmes de “performance”. Ils n’avaient apparemment pas compris que le vrai problème, c’était un code de mauvaise qualité dès le départ
    Cela dit, ils ont quand même récupéré des développeurs réellement compétents, donc ça a peut-être aidé dans une certaine mesure
    Mais au passage, Bun est passé d’un projet public à quelque chose de plus proche d’un outil interne à Anthropic, et il est maintenant assez surprotégé par l’argent de l’IA tout en ayant perdu une bonne part de son focus
    J’espère qu’au moins une partie du travail investi dans Bun pourra être sauvée quand la bulle éclatera. Je doute qu’Anthropic le maintienne sur le long terme. Ce n’est pas une entreprise qui vend du support runtime, ni une société de la taille de Google capable d’entretenir un runtime sur le côté

• En mettant de côté un instant l’intervention de l’IA, je pense que c’est une bonne évolution
  Bun, en utilisant Zig, avait énormément de crashs et de bugs mémoire, contrairement à Deno qui repose sur Rust
  Bien sûr, si le port Rust de Bun contient beaucoup de unsafe, cela ne résoudra pas tout comme par magie, mais ce sera quand même mieux

  • Je me demande s’il existe des statistiques ou une source montrant que Bun a énormément de crashs et de bugs mémoire. Je ne dis pas que c’est faux
    Le fait que les parties laides deviennent plus visibles via unsafe et poussent ainsi au refactoring me semble aussi relever en partie de choix propres à Bun, pas seulement du langage
  • Je me demande si l’affirmation est que Zig “entraîne énormément de crashs et de bugs mémoire”
    Si c’est le cas, cela voudrait dire qu’il est pratiquement impossible de produire du logiciel de haute qualité avec ce type d’outil, non ? Pourtant beaucoup de choses de qualité ont été faites en C/C++, donc je me demande ce que Zig ferait de travers
  • Comme unsafe est explicitement marqué, c’est plus facile à repérer, et cela crée naturellement une liste de problèmes à résoudre

• Il a fallu 6 jours pour faire cela. Même si ça ne débouche pas au final sur un résultat significatif, cela montre comment les tokens et la charge de travail s’articulent aujourd’hui et à l’avenir
  Il va devenir plus difficile de rivaliser avec des individus ou des entreprises qui disposent de davantage de ressources de calcul. Ils pourront simplement faire des choses que je ne peux pas faire

  • Il est bien connu que la traduction d’un projet d’un langage à un autre, quand il dispose d’une bonne suite de tests, est un cas typique où les grands modèles de langage excellent
    Quand on peut utiliser la base de code finie comme exemple et valider avec une suite de tests, il est beaucoup plus facile d’itérer vers le résultat voulu. Le modèle voit déjà quel est l’objectif et comment il a été réalisé une première fois, donc c’est un problème bien plus simple que de partir d’une spécification
  • On aurait pu dire la même chose de la machine à vapeur ou de l’électricité. Et ce n’est même pas qu’une simple analogie. La magie de ces choses tient au fait qu’elles sont des moteurs universels d’information
    On y met du capital, on les construit avec des techniques extensibles bien comprises, on les branche à l’électricité et de la valeur en sort
    L’idée, c’est que, dans le monde moderne, il n’y a pas eu de séparation durable entre “ceux qui ont” et “ceux qui n’ont pas” avec l’électricité, et qu’il n’y aura probablement pas cela ici non plus
  • Je n’en suis pas sûr. Les très bons produits viennent généralement du fait de faire une ou deux choses très bien, pas d’en faire beaucoup
    Pour l’instant, ce qu’on voit ressemble surtout à “waouh, je suis maintenant un ingénieur 10x !” et à beaucoup plus de code produit, mais sans direction ni goût clairs. La plupart du travail actuel basé sur les grands modèles de langage ressemble juste à du bruit
  • Non. Ces agents deviennent de plus en plus faciles à faire tourner en local
    Je ne sais pas si tu as essayé Qwen 3.6 27b, mais ce qu’il peut faire vu sa taille est dingue. Si on gère bien le contexte, de petits projets peuvent être réalisés à 100 % en vibe coding
    Comme pour le calcul, ces modèles finiront eux aussi par entrer dans une logique de concurrence par les prix
  • Je me demande combien cela aurait coûté en dollars au tarif standard d’Anthropic. Est-ce que quelqu’un pourrait au moins en faire une estimation grossière ?

• Beaucoup de gens prennent cela au pied de la lettre, mais une grande partie de cette réussite est possible grâce à une suite de tests extraordinairement vaste et complète, au-delà des standards habituels, construite auparavant

  • Cela reste impressionnant, car même les ingénieurs les plus compétents auraient mis bien plus de temps à obtenir ce résultat
    Quand ils communiqueront dessus plus tard, j’aimerais qu’ils mentionnent aussi combien d’efforts humains il a fallu pour concevoir et curer la suite de tests qui a rendu cette vitesse possible
    Les suites de tests fonctionnent presque comme un environnement idéal pour la génération actuelle de grands modèles de langage. Une suite suffisamment complète devient une spécification que l’agent peut implémenter à sa manière, et ici cette implémentation était en Rust
    Avec des tests aussi bien conçus que dans un projet comme Bun, on pourrait presque, dans certains cas, jeter tout le code source et ne laisser accès qu’aux tests pour tout réimplémenter depuis zéro
  • Si cette suite de tests est à ce point “au-delà des standards” qu’elle rend cette tâche presque seule possible par rapport à d’autres projets, je me demande comment cela peut coexister avec l’idée que Bun serait particulièrement instable parmi les programmes Zig, au point d’exiger une réécriture
    Si la responsabilité incombe aussi en partie à la suite de tests, je me demande ce que cela implique pour le port Rust
  • Donc il faudrait regarder uniquement le fait qu’on peut faire ça en 6 jours
    Et ignorer les centaines de milliers d’heures investies dans l’architecture d’origine et la suite de tests qui ont rendu cela possible ?

• Cela ressemble à un bon exemple de prudence concernant les portages Rust réalisés avec l’aide de l’IA
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Réussir les tests ne veut pas forcément dire que ça fonctionne
    Le compilateur C Claude code passait 100 % des tests gcc, mais n’arrivait même pas à exécuter hello world
  • La leçon à tirer de ces exemples est un peu différente. Les grands modèles de langage construisent en fonction de la boucle de feedback qu’on leur donne
    Si on ne leur donne que des tests de logique, ils ne prendront absolument pas en compte la vitesse. Si on inclut des tests mesurant la vitesse et qu’on leur dit de respecter la performance, ils le feront aussi
    C’est la même famille d’erreurs que les autres défauts des grands modèles de langage. Ils n’ont aucun contexte de bon sens sur ce que les humains jugent important. Si on n’impose pas des frontières, ils les ignorent
  • Si ça vous intéresse, la discussion a eu lieu ici : LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - mars 2026, 422 commentaires

• Quelle époque incroyable pour être en vie
  Les dynamiques fondamentales du secteur et des métiers ont changé en un temps ridiculement court, pratiquement du jour au lendemain
  Certains jours, je suis enthousiasmé par tout ce que je peux désormais faire. Je peux construire presque instantanément tout ce que je veux, et 100 % de ce que j’imaginais en logiciel peut devenir réel
  Certains jours, j’ai peur de ce qui va arriver au marché de l’emploi
  Tout à coup, on peut obtenir énormément avec très peu, et la quantité de logiciels dont le monde a besoin a une limite
  Est-ce que toutes les entreprises dont le modèle économique principal consiste à vendre du logiciel vont finir par disparaître ?
  Que se passera-t-il si seules certaines entreprises ou certains gouvernements ont accès aux meilleurs modèles ?

  • Prenons un logiciel comme un système de billetterie
    Est-ce que 100 entreprises ayant chacune 1 milliard de tokens pourraient construire un meilleur produit qu’un éditeur spécialisé disposant de 100 milliards de tokens ?
    Les éditeurs de logiciels et les SaaS du type “générateur de logos” sont sans doute déjà morts, mais les éditeurs de systèmes de billetterie devraient s’en sortir, à moins que la prochaine génération de grands modèles de langage n’intègre directement un système de billetterie. Les effectifs peuvent diminuer, mais rien n’est certain
  • Déjà à l’époque de l’éclatement de la bulle internet, on entendait souvent dans l’industrie du logiciel que le secteur était “trop saturé” et que les étudiants et chercheurs d’emploi feraient mieux de ne pas s’y engager
    L’idée était qu’il n’y avait pas grand-chose à se partager par rapport au nombre de personnes qui affluaient, et l’effondrement renforçait ce récit
    Pourtant, même en étant étudiant à l’époque, on pouvait voir que le champ du logiciel était pratiquement infini. Presque tout travail cognitif que nous faisons manuellement peut être transformé en logiciel. J’avais commencé à essayer d’en faire la liste, puis j’ai vite compris qu’il y avait déjà bien trop à faire
    J’ai aussi compris qu’à mesure qu’on fait les choses de nouvelles façons, encore plus de nouveaux travaux imprévisibles apparaissent. Les possibilités étaient innombrables, et il était évident que le récit de la “saturation” venait d’un manque d’imagination et de compréhension de ce qu’est réellement le logiciel
    Je savais donc que ce domaine ne serait jamais saturé. Il était impossible d’épuiser les choses à transformer en logiciel
    Mais aujourd’hui, c’est différent. Bien sûr, on continuera à créer de nouveaux logiciels, mais je me demande maintenant si la vitesse à laquelle nous écrivons du logiciel peut dépasser la vitesse à laquelle nous imaginons de nouvelles choses à faire
  • Les entreprises et les gouvernements auront accès à de meilleurs modèles que le grand public. En fait, Mythos en est déjà un exemple
    Le grand public pourra quand même s’aider lui-même avec des modèles en retard sur la frontière de pointe

• À défaut d’autre chose, c’est intéressant à observer comme expérience en cours
  Ce qui m’intéresse d’abord, c’est le degré de couverture et de qualité de la suite de tests dès le départ. Ce n’est pas pour chercher la petite bête, mais même avec 100 % sur toutes les plateformes, je me demande à quel point l’équipe Bun pourrait se sentir en confiance pour une migration

• Après l’affaire Ubuntu coreutils la semaine dernière, j’ai une très mauvaise opinion des réécritures Rust à 99,8 % de compatibilité aux tests
  En cliquant sur le tweet lié ici, j’ai eu un frisson, et désormais ce genre de chose me fait ressentir exactement l’inverse. J’ai presque envie de chercher la sortie