La PR de réécriture de Bun en Rust a été fusionnée

 (github.com/oven-sh)
9 points par GN⁺ 9 시간 전 | 4 commentaires | Partager sur WhatsApp
  • La PR #30412 apporte une modification de réécriture de Bun en Rust, fusionnée de la branche claude/phase-a-port vers main le 14 mai 2026
  • L’ampleur du changement est indiquée comme 6 755 commits, 2 188 fichiers, et +1,009,257/-4,024 lignes
  • Jarred-Sumner a indiqué qu’un article de blog détaillant le sujet serait publié prochainement
  • Il est expliqué que cette modification fait passer la suite de tests existante de Bun sur toutes les plateformes, et qu’elle a corrigé plusieurs fuites mémoire et tests instables
  • La taille du binaire a diminué de 3 à 8 Mo, et les benchmarks sont présentés comme neutres ou meilleurs en termes de performances
  • La raison la plus importante avancée est que les bugs mémoire, qui ont coûté à l’équipe d’importants efforts de développement et de débogage pendant des années, peuvent désormais être détectés et évités grâce aux outils d’assistance du compilateur
  • Il est précisé que la base de code reste globalement la même, et que l’architecture et les structures de données ont également été conservées
  • Bun continue d’utiliser peu de bibliothèques tierces, et il est explicitement précisé que async Rust n’est pas utilisé
  • Les utilisateurs peuvent tester ce changement avec bun upgrade --canary
  • Jarred-Sumner a demandé de signaler les problèmes en ouvrant une issue, et a indiqué qu’il pourrait verrouiller le fil si les échanges s’échauffent
  • Des travaux d’optimisation restent encore à faire avant l’intégration dans la version non-canary
  • Un travail de nettoyage reste également à faire, et sera mené dans une série de PR de suivi

À lire aussi

4 commentaires

 
xguru 9 시간 전

Waouh, une PR d’un million de lignes mergée. Ils passent carrément de Zig à Rust en une seule fois.
Il disait qu’il ne savait pas si ça allait être mergé ou pas~~ et une semaine plus tard, ils remplacent d’un coup le langage d’un code qui fonctionnait déjà bien haha
J’ai l’impression qu’il se passe quelque chose de monumental grâce au codage assisté par IA.
 
heycalmdown 5 시간 전

Sérieux ? Ils disaient que c'était juste pour tester et qu'ils risquaient fort de ne pas l'utiliser.
 
freedomzero 4 시간 전

Comme Zig ne le fait pas, ils passent direct à Rust avec un culot impressionnant mdr
 
GN⁺ 9 시간 전
Commentaires sur Hacker News

  • Quand l’annonce dit que la réécriture a pris une semaine, on se demande combien de temps a été nécessaire pour préparer ce fichier d’instructions très détaillé qui mappe les idiomes Zig vers les idiomes Rust : https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
    En plus, si on regarde les sections Pointers & ownership et Collections, la base de code de Bun utilisait déjà des types internes de smart pointers préparés pour correspondre en 1:1 à leurs équivalents Rust, et le crate Rust bun_collections existait déjà
    Cette réécriture semble avoir été préparée de longue date, et ressemble à quelque chose que l’équipe Bun a proposé pendant les négociations d’acquisition par Anthropic

    • Quand je lis des articles sur les LLM, je ne sais plus ce qui est vrai, et c’est pareil avec les commentaires Hacker News ici
      Les montants en jeu sont tellement énormes qu’il y a clairement une incitation à infiltrer la communauté avec des astroturfers marketing, et certains tombent simplement dans la logique de camp
      Maintenant qu’Anthropic possède Bun, ils ont aussi tout intérêt à faire paraître ce travail plus facile qu’il ne l’était réellement
    • En mettant de côté des éléments comme la qualité du code Rust produit, si le nombre de lignes est raisonnable, ou à quel point la base de code était déjà prête pour ce travail, un document de 622 lignes peut quand même être vu comme un coût relativement faible parmi les livrables préparatoires qui peuvent améliorer la cohérence ou la qualité d’environ 1 million de lignes générées
      L’ampleur de la sortie donne l’impression d’un effet multiplicateur
      Je me demande en revanche combien de connaissance implicite a été nécessaire pour élaborer ces règles, et combien de fois ce fichier a été amélioré de manière itérative
      Par exemple, j’aimerais savoir quelle part de ces règles provient de cas d’échec rencontrés au fil des itérations de traduction
    • Tu parles de using internal smart pointer types that map 1-to-1 to Rust equivalents, mais les smart pointers n’ont pas été inventés par Rust
      Si tu écris du code dans un autre langage avec des pointeurs, tu modélises déjà mentalement les mêmes types
      Et c’est faux de dire que le crate Rust bun_collections existait déjà
      Il ne s’agit que d’une partie du PR de la base de code, pas de quelque chose qui existait auparavant
    • C’est comme la démo gcc d’Anthropic
      Pour réduire le scepticisme et encore mieux alimenter l’ambiance pré-IPO, il serait pourtant très facile de publier dans un dépôt séparé le travail caché nécessaire pour faire avancer l’IA, afin que tout le monde puisse reproduire le résultat
      Après tout, ce que les clients veulent obtenir, c’est bien 1 million de lignes de code utilisables en “7 jours”, non ?
      Tout le monde pourrait essayer de le reproduire dans son propre workflow, et les métriques d’usage d’Anthropic grimperaient aussi
      Si c’était vraiment un résultat formidable, j’aurais pensé qu’ils commenceraient par un billet de blog avec lien et consignes
      Cela dit, il est possible qu’un billet soit en train d’être rédigé pendant que j’écris, et que cela me donne tort
    • Il me semble que la version Zig de Bun avait 3 types de pointeurs qui se mappaient proprement aux types de pointeurs Rust existants, et que pour les 7 ou 8 restants il a fallu créer de nouveaux types
      C’est ça le cœur de la théorie du complot ?
      bun_collections non plus n’a pas l’air beaucoup plus ancien que le guide de portage

  • +1009257 -4024 : Bun dépasse désormais 1 million de lignes de code Rust
    On se rapproche de la taille du compilateur Rust lui-même
    Cela dit, BunJS est essentiellement un wrapper d’interpréteur JavaScript et une réimplémentation de bibliothèques NodeJS, donc assez proche d’un wrapper de la bibliothèque standard Rust
    BunJS devient un peu le canari de la gestion de la complexité logicielle à l’ère des LLM

    • mostly a JavaScript interpreter wrapper n’est pas exact
      Bun est un transpileur (parseur) JavaScript et CSS batteries incluses, un minifier, un bundler, un gestionnaire de paquets façon npm, un test runner façon Jest, et il fournit aussi des API runtime intégrées comme des clients Postgres, MySQL et Redis
      Il est donc naturel que le volume de code soit énorme
    • Bun n’est pas un interpréteur JavaScript, c’est davantage une réimplémentation des bibliothèques NodeJS et de plusieurs autres bibliothèques
      Bun utilise JavaScriptCore comme moteur JS, donc Bun lui-même ne fait pas, ou en tout cas ne devrait pas faire, le parsing JavaScript, l’interprétation ni le JIT
      Édition : j’avais mal lu. Comme il était écrit “JavaScript interpreter wrapper”, c’est bien formulé
    • Je ne sais pas si c’est uniquement à cause du + au début ou d’un autre facteur qui fait détecter ça comme un numéro de téléphone sur iOS, mais sur mobile la variation du nombre de lignes est soulignée et on peut taper dessus pour appeler
      Si c’est seulement à cause de la taille du diff, c’est assez drôle
    • La base de code de Bun avait déjà un volume de code similaire avant la réécriture
      Il n’y a rien d’étrange à ce que la réécriture aboutisse à un nombre de lignes comparable
    • Un wrapper JavaScriptCore de 1 million de lignes est un excellent exemple de ce que les agents peuvent faire

  • $ rg 'unsafe [{]' src/ | wc -l donne 10428, et $ rg 'unsafe [{]' src/ -l | wc -l donne 736
    Par langage, on a : Rust 1443 fichiers, 929213 lignes ; Zig 1298 fichiers, 711112 lignes ; TypeScript 2604 fichiers, 654684 lignes ; JavaScript 4370 fichiers, 364928 lignes ; C 111 fichiers, 305123 lignes ; C++ 586 fichiers, 262475 lignes ; C Header 779 fichiers, 100979 lignes

    • En Rust, c’est appréciable de pouvoir rechercher explicitement le code potentiellement unsafe comme ça
      Comment recherche-t-on le code dangereux en Zig ?
      Ou faut-il simplement partir du principe qu’il est partout ?
    • Si la moitié des fichiers contiennent le mot-clé unsafe, ça ne ressemble pas à une bonne réécriture
      Si presque la moitié du code reste unsafe, quel est alors l’intérêt de le réécrire en Rust ?
    • J’espère que Mythos est réellement le meilleur au monde comme ils le prétendent. Ils vont vraiment en avoir besoin maintenant
    • On a de la sécurité mémoire à la maison !
      Ce qu’il y a à la maison : 10428

  • On est encore en train d’écrire le billet de blog sur le sujet, et on partagera plus de détails
    Si vous voulez du contexte, parcourez la liste de correctifs dans les notes de version de Bun v1.3.14 et des versions précédentes
    Rust ne corrigera pas tout cela. Les fuites dues à des références conservées trop longtemps, ou tous les problèmes de réentrance à travers les frontières JS, restent de notre responsabilité
    Mais une bonne partie de cette liste concerne des use-after-free, des double-free, ou des oublis de libération sur des chemins d’erreur, et ceux-là deviennent soit des erreurs de compilation, soit du nettoyage automatique

    • Il disait ceci il y a 9 jours[0] :
      I work on Bun and this is my branch
      This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
      Ce n’était peut-être pas une surréaction, finalement ?
      [0]: https://news.ycombinator.com/item?id=48019226
    • J’attends le billet de blog avec intérêt
      Je me demande si vous comptez exécuter côte à côte les binaires Zig et Rust sur un large éventail d’applications réelles, ou si possible en shadow execution en production, afin d’éliminer les bugs
    • Si j’étais client payant, je voudrais savoir combien ce travail va coûter
      Pouvez-vous donner un ordre de grandeur ?
    • Je me demande si vous avez mis en place, ou prévoyez de mettre en place, une sorte de fuzzing end-to-end comparant les deux binaires
      J’aimerais aussi connaître le plan concret pour publier cette version sans casser les workflows des utilisateurs
    • Est-ce que cela pourrait corriger les problèmes de stabilité de l’API Bun Workers ? https://bun.com/docs/runtime/workers

  • Il y a environ 9 jours, Jarred écrivait qu’il n’était pas du tout certain que cela soit fusionné et que tout ça relevait de la surréaction
    C’est ironique

    • On dirait un cas d’école de leadership open source
      Imaginez le chaos si Linus disait qu’il n’allait pas réécrire le noyau Linux, puis qu’un beau matin il fusionnait une réécriture Rust assistée par machine de l’ensemble du code
    • Une fois que tu ne possèdes plus l’entreprise, on peut ignorer sans risque ce que tu dis
      Il fallait bien justifier les coûts en tokens engagés
    • Cela n’exclut pas pour autant la possibilité que ça soit fusionné

  • Waouh, ça va être fascinant à suivre
    Il n’y a aucune chance que ce code ait été relu, mais peut-être sommes-nous désormais entrés dans une ère post-humaine où l’on peut faire confiance aux modèles pour écrire et relire du code
    C’est comme Gastown, mais dans un projet bien plus connu
    Je suis curieux de voir comment ce projet va pouvoir ajouter de nouvelles fonctionnalités à l’avenir, voire s’il pourra encore en ajouter
    Est-ce que quelqu’un sait exactement comment Anthropic utilise Bun ?
    Est-ce une partie de Claude Code ?
    Utiliser Bun m’inquiète pas mal à l’avenir, mais je ne sais pas dans quelle mesure cette inquiétude s’applique aussi à l’usage de Claude

    • Cela ne veut absolument pas dire qu’on peut faire confiance aux modèles pour écrire et relire du code
    • Tous les tests sont passés
      Si on ne peut pas faire confiance à une suite de tests pour détecter une traduction automatique entre langages, alors on ne devrait de toute façon pas lui faire confiance du tout :)
    • Je ne sais pas comment Anthropic utilise Bun, mais on dirait que cela sert à déplacer la fenêtre du débat vers l’idée qu’on peut fusionner à l’aveugle des millions de lignes sans que ce soit un problème
    • Dans quel état est la suite de tests ?

  • Je suis en fait enthousiaste à l’idée d’expérimenter la traduction automatique, mais j’ai peur que cela génère beaucoup de problèmes de rétrocompatibilité
    J’ai commencé à regarder les commits, et grosso modo ils résolvent les problèmes de “tests qui ne passent pas” en modifiant les tests eux-mêmes
    Le vrai travail pour faire en sorte que ça fonctionne correctement sur des programmes déjà déployés ne fait que commencer
    Le seul point rassurant, c’est que la communauté JS côté serveur semble déjà habituée, pour une raison ou une autre, aux ruptures fréquentes

    • L’idée qu’un code que personne n’a relu entre dans le runtime que j’utilise me met mal à l’aise
      Mais si ça fonctionne réellement sans gros problème, ce sera assez stupéfiant
    • Je ne sais pas si ces décisions ont été prises par un LLM, mais j’ai toujours trouvé que Claude avait davantage tendance à adopter des comportements suspects comme modifier les tests plutôt que trouver la bonne solution au problème
      GPT/Codex est plus honnête sur ce point
    • Je ne pense pas que cela deviendra une release stable immédiatement, mais je serai heureux qu’on me prouve le contraire
      Je suis sceptique sur l’ensemble de cette réécriture, et Jarred Sumner a une audience internet si énorme que cela donne une impression de publicité
    • Exemple de résolution d’un problème de “tests qui ne passent pas” en modifiant les tests eux-mêmes : https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
      Formidable ! Il suffit d’ajouter arbitrairement sleep(1) dans les tests. Ne vous inquiétez pas, tout ira bien !
    • J’aimerais parcourir les tests pour voir s’il y a eu de vrais changements importants, mais GitHub n’arrive même pas à charger le diff

  • Les quelques projets dans lesquels j’utilise Bun vont être migrés vers autre chose
    Je n’ai pas confiance dans une gouvernance qui autorise des changements aussi téméraires

    • Deno est excellent, mais je trouve qu’il n’est pas autant apprécié qu’il devrait l’être
      Il est bien conçu à la base, donc il n’a même pas besoin d’être réécrit
    • Moi, je vais simplement rester sur node
      D’un côté, regarder comment se passera ce baptême du feu sera intéressant, et à long terme j’ai quand même l’impression que les problèmes finiront par être résolus

  • Il y a un fil très instructif. Il date d’il y a une semaine, quand Jarred se désengageait encore une fois de la décision de fusion, tandis qu’une foule de fantassins attaquait les gens qui prédisaient que cela serait bientôt fusionné :
    https://news.ycombinator.com/item?id=48073680
    Avec le recul, ça n’a pas très bien tenu, n’est-ce pas ?

    • Passer en 10 jours de “ce fil entier est une surréaction. 302 commentaires sur du code qui ne fonctionne pas. Nous n’avons pas décidé de réécrire. Il y a de très fortes chances que tout ce code soit complètement jeté” à une fusion complète, même en comptant ce qui ressemblait au départ à une simple curiosité expérimentale, cela paraît complètement fou
    • Je suis toujours surpris de voir combien il existe de courtisans du pouvoir qui se moquent finalement assez peu de savoir quelles bottes ils lèchent

  • Si ça se passe ne serait-ce qu’un peu mal, les moqueries sur le dealer défoncé à sa propre marchandise vont être interminables et sinistres

    • Trop de gens ne sont pas émotionnellement préparés à l’éventualité que cela ne se passe pas du tout mal
    • Le simple fait d’avoir vu le code source divulgué de Claude Code n’était-il pas déjà largement suffisant comme motif de moquerie ?
    • Ils sont déjà défoncés à leur propre marchandise
      Tu as lu le papier Mythos ? L’anthropomorphisme y est vraiment intense
      C’est peut-être juste du buzz à bas coût, mais s’ils croient vraiment que les LLM sont conscients… wow