Réécriture Rust de Bun : « la base de code échoue aux vérifications miri élémentaires et autorise de l’UB en Rust sûr »

• Cette issue est actuellement ouverte, et la discussion a été verrouillée comme hors sujet et limitée aux collaborateurs, avec des correctifs associés reliés à #30728 et #30876
• Le signalement explique qu’une valeur créée avec PathString::init peut toujours appeler slice() après le drop du Box d’origine, ce qui amène Miri à signaler un Undefined Behavior fondé sur une référence pendante
• Le code de reproduction passait un tampon créé avec Box::new(*b"Hello World") à PathString::init(&*test), puis appelait init.slice() après drop(test) ; Miri renvoyait une erreur au niveau de core::slice::from_raw_parts
• robobun a confirmé que le problème se reproduisait, en résumant que PathString::init est une fonction sûre mais qu’elle efface le lifetime de la slice, ce qui permet de créer un &[u8] pendant
• Le correctif lié #30728 vise à transformer en unsafe fn la faille parallèle de PathString::init et dir_iterator::next(), et à ajouter sur environ 70 sites d’appel des commentaires SAFETY explicitant l’allocation de support
• Il est aussi précisé que ce correctif inclut un compile_fail doctest imposant la présence du mot-clé unsafe dans trois signatures, ainsi qu’une correction d’une fuite de descripteur de fichier sur erreur readdir dans le resolver
• AwesomeQubic ajoute que PathString::init efface également la provenance et échoue aussi avec MIRIFLAGS=-Zmiri-strict-provenance
• JavaDerg explique que init reçoit le lifetime implicite de &[u8], l’efface via une opération unsafe, puis retourne un Self qui semble 'static, autorisant ainsi use-after-free et invalid aliasing
• JavaDerg avertit que, dans le modèle de sûreté de Rust, l’UB peut provoquer des problèmes à des endroits inattendus, qu’un examen plus large de l’usage de unsafe est nécessaire, et qu’il n’est pas approprié de traduire à l’identique en Rust les approches de gestion mémoire d’autres langages
• robobun a ajouté comme commits associés les tests PathString::init signature stays unsafe et dir_iterator: make next() unsafe; audit call sites
• SimonReiff indique qu’un grep de unsafe dans les fichiers Rust du dépôt, hors commentaires, retourne 13255 lignes, et demande un retour arrière immédiat ainsi qu’une discussion sur la politique et les procédures d’usage du code généré par IA
• Jarred-Sumner explique que le port Rust part actuellement d’un mapping 1:1 aussi proche que possible du code Zig d’origine et qu’il est en cours d’amélioration, tout en demandant de continuer à signaler via de nouvelles issues les bugs ou comportements non sûrs du code Rust

[GN⁺]

Commentaires sur Hacker News

• Si je me suis intéressé à Bun au départ, c’est parce qu’il était écrit en Zig, et si Zig m’attirait, c’est parce que je faisais confiance aux décisions et au goût d’Andrew Kelley
  Si Bun m’a ensuite davantage intéressé, c’est aussi parce que les autres raisons relevaient finalement de choix que je pouvais respecter, et même après le rachat par Anthropic, j’essayais de rester prudemment optimiste
  Mais cette fois, cela ressemble à une décision difficile à approuver ; le problème n’est pas Rust en soi, mais si Anthropic gère Bun de cette manière, il devient difficile de continuer à parier dessus comme composant fiable de sa boîte à outils
  Il faut faire confiance non seulement au code, mais aussi à la manière de penser derrière, et pour l’instant cela donne l’impression d’un outil réservé à l’usage interne d’Anthropic

  • Bun est vraiment un projet intéressant, mais le nombre de segmentation faults remontés dans les issues me paraissait déjà trop inquiétant pour un usage en environnement de production sérieux
    Cette orientation peut être une manière d’y remédier, donc à voir
  • Je comprends, mais mon point de départ est assez différent
    En tant qu’ancien fan de Deno, Bun me semblait être un Deno moins ambitieux, et comme je n’avais pas envie d’apprendre Zig, j’avais peu de chances de toucher à Bun lui-même, même comme hobby
    Mais au fil des dernières années, en essayant de maintenir un assez gros codebase TypeScript de manière moins dépendante du runtime, je me suis progressivement ouvert à Bun, et même si je ne voulais pas faire d’un runtime TypeScript particulier une exigence, Bun continuait à offrir des raisons que Deno offrait aussi : Postgres, SQLite, S3, WebSocket, stockage local de secrets, bundling, compilation, vitesse
    Aujourd’hui, je transforme plusieurs serveurs API et serveurs d’apps frontend en exécutables uniques bun build --compile --bytecode, que je peux lancer et déployer presque partout
    Cela dit, je ne pense pas que cette approche soit courante, et si ce portage piloté par LLM échoue, je suis dans une position idéale pour regretter toutes mes décisions liées à Bun
    Mais si ça ne rate pas, c’est intéressant. Ce sera un bon exemple de ce qu’il est possible de faire avec les LLM, et le fait que Bun soit désormais développé en Rust est, pour moi, un plus
    Et même si ça échoue, ce sera une information importante. Bun est l’un des principaux runtimes TS/JS, et Anthropic dispose de ressources énormes, d’un accès aux derniers modèles et d’un budget quasiment illimité ; s’ils n’y arrivent pas, cela voudra presque dire que c’est encore vraiment impossible
  • Je serais curieux de savoir pourquoi Bun vous attirait plus que Deno

• Si le but était de déplacer Zig vers du Rust non sûr, je ne comprends pas pourquoi ils n’ont pas créé un outil de traduction
  Ils auraient pu obtenir une transformation déterministe en mappant les structures des langages en un-à-un et en codant en dur les motifs du codebase ; comme disait un ami, on aurait même pu faire quelque chose du genre « brancher zig translate-c sur c2rust »
  Le résultat actuel est encore moins digne de confiance que l’entrée. L’entrée n’était pas memory-safe, mais c’était du code écrit par des humains ; la sortie n’est pas memory-safe non plus, elle est issue de vibe coding, et on dirait qu’aucun humain ne l’a vraiment relue
  Je ne vois pas l’intérêt d’abuser d’une IA agentique pour ce type d’usage

  • Si vous avez déjà vu le résultat de c2rust, il est difficile de dire ça
    Cela imite la sémantique des pointeurs non sûrs du C au moyen d’une bibliothèque de fonctions Rust non sûres, et le résultat est atroce
    Il y a quelques années, quelqu’un a essayé de convertir avec c2rust pendant que je regardais un bug d’OpenJPEG, et le Rust non sûr généré produisait lui aussi un segmentation fault exactement au même endroit que le code C
    C’est compatible, mais pas sûr
    L’idée essentielle, c’est qu’il ne faut pas faire de manipulation de chaînes en C ni en Rust non sûr. Ce sont des outils totalement inadaptés à la tâche
  • Ils l’ont fait. Un outil de traduction extrêmement dynamique
  • Dire « il suffit de brancher zig translate-c sur c2rust » ne marche pas aussi simplement qu’on l’imagine
    Ces outils génèrent beaucoup d’erreurs et rendent le code très verbeux et difficile à raisonner
    Ça peut convenir à de petites applis, mais pas à une réécriture complète
  • J’ai dit presque la même chose dans un autre fil, mais j’ai une vision un peu différente de la façon d’écrire du logiciel
    Plutôt que de traduire Zig vers Rust, je pense qu’il vaudrait mieux écrire un parseur JPEG en Python statique, puis l’abaisser vers Zig et Rust avec des structures idiomatiques propres à chaque langage
    J’ai créé pour cela un parseur d’un dialecte Python conçu pour ce genre d’objectif, et j’essaie d’y intégrer certaines fonctionnalités Rust/Zig qui facilitent la traduction tout en gardant la compatibilité avec la plupart du code Python
    Un parseur JPEG fait aussi partie des ressources d’exemple
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • La bonne manière de porter un codebase dans un autre langage, c’est d’analyser l’arbre syntaxique et d’appliquer des transformations déterministes et vérifiées

• Cette issue prête à confusion
  Le problème n’est pas l’existence même de comportement indéfini que miri peut détecter, mais le fait d’exposer une API capable de provoquer un comportement indéfini depuis du code sûr. Et miri ne peut le détecter que si l’on écrit un test qui le démontre
  Pendant un portage initial depuis un langage non sûr, ce genre de chose n’est pas totalement déraisonnable
  L’équipe Bun semble d’ailleurs examiner ensuite si les fonctions qui encapsulent du code non sûr sont correctes
  Le fait d’avoir marqué temporairement certaines fonctions non sûres comme sûres pendant la phase de portage n’est pas en soi un énorme problème, mais les avoir fusionnées dans le dépôt principal dans cet état est un peu étrange
  Le vrai problème, c’est de publier un code dans cet état
  Ce qui est regrettable, c’est qu’ils n’aient pas configuré l’exécution immédiate des tests avec miri. Les LLM réagissent bien à de bons tests
  Je le pense non pas à cause de cette issue GitHub, mais parce qu’un autre test [1] invoque réellement un comportement indéfini que miri détecterait. Cela dit, le code testé ne semble utilisé nulle part, donc l’impact réel ne paraît pas très important
  On en est au début du portage, donc cela pourra être corrigé plus tard, et il sera peut-être même possible d’éliminer du code non sûr qui n’est en fait pas nécessaire
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - les pointeurs dérivés de la première référence mutable sont invalidés lorsqu’une nouvelle référence mutable au même objet est créée. En termes de style C, on peut voir une « référence mutable » comme une « référence restrict sur laquelle on effectue de petites modifications »
  Pour faire les choses correctement, il aurait fallu dériver tous les pointeurs de la même référence mutable ; ils ne l’ont simplement pas fait
  Si vous débarquez en masse sur GitHub pour spammer, cela ne fera que réduire les chances qu’ils travaillent en public. J’aimerais qu’on évite ça
  Et il vaut mieux suspendre son jugement jusqu’à ce que ce soit dans un état publiable. Évaluer un travail en cours n’est ni très juste, ni très intéressant

  • Quand un projet atteint pour la première fois la version 1.0, beaucoup de gens s’attendent à ce que la branche main fonctionne toujours
    Parce que le CI/CD repose au fond sur l’hypothèse que chaque commit doit fonctionner
    Du code en cours de développement qui ne fonctionne pas, comme pour une réécriture complète, devrait être fait sur une branche
    Cela permet aussi de garder un main opérationnel lorsqu’il faut, par exemple, faire un correctif de sécurité

• Ce résultat n’a rien de surprenant, puisque la demande était presque celle d’un portage littéral
  On peut aussi considérer qu’il vaut mieux d’abord déplacer Bun vers un langage doté d’un système de types plus fort, puis s’appuyer sur ce système pour améliorer ensuite le code
  Cela paraît préférable à exiger la perfection dès la première étape

  • C’est effectivement ce qu’ils sont en train de faire
    Ils traitent les issues au fur et à mesure
  • Il suffira probablement d’ajouter au prompt « assure-toi qu’il n’y ait pas de comportement indéfini »
  • On dirait qu’on peut maintenant mettre la réécriture sous pression avec des outils comme miri, puis laisser Claude Code l’améliorer automatiquement
  • Il n’est pas surprenant d’avoir du comportement indéfini dans du Rust en partie non sûr et en grande partie traduit littéralement
    En revanche, il est décevant que les API de ce code Rust puissent provoquer un comportement indéfini sans être marquées unsafe
    Si j’avais fait ce type de traduction, j’aurais été conservateur et j’aurais d’abord marqué tout ou presque comme unsafe
    Ensuite, il aurait suffi de vérifier progressivement la sûreté de chaque morceau

• Honnêtement, j’ai été un peu surpris par l’affirmation selon laquelle ils l’auraient rendu complètement fonctionnel en une semaine
  Mon projet perso https://tsz.dev a une ambition similaire, mais je ne peux pas prétendre avoir réussi
  Je continue d’ajouter des tests pour vérifier le comportement, et même après avoir fait passer tous les tests de TypeScript lui-même, je trouve encore, comme prévu, des bugs
  Le niveau d’exigence pour reproduire le comportement de tsc est vraiment extrêmement élevé
  https://github.com/type-challenges/type-challenges
  Je ne suis pas opposé au fait d’écrire beaucoup de code avec des LLM, mais maintenant qu’ils permettent de produire du code à cette vitesse, la validation doit être 100 fois plus solide

  • Ce qui choque, c’est d’avoir fusionné après une « expérience » en une semaine un codebase d’un million de lignes qui a très probablement été très peu relu
    Je ne suis pas opposé à l’usage d’agents, mais faire ça dans la précipitation et prendre la communauté de court donne une image extrêmement amateur
    C’est le genre de comportement qu’on attendrait d’un jeune ingénieur très enthousiaste
  • https://tsz.dev/sound-mode/
    C’est excellent. TypeScript a besoin de plus de choses de ce genre, et j’espère que cela gagnera en visibilité au point que Microsoft l’adopte
    Cela dit, je serais prudent avec le nom sound mode
    La phrase « ce n’est pas une preuve de solidité au sens mathématique, et cela ne rend pas vrais les fichiers .d.ts tiers » mélange deux choses totalement différentes
    D’abord, la solidité est un concept mathématique. Si quelque chose est sound, alors c’est réellement sound, et cela signifie qu’on peut faire confiance au compilateur sans avoir à vérifier manuellement les détails
    Des bugs d’implémentation peuvent certes le faire mal fonctionner, mais ils peuvent être corrigés ; la soundness signifie qu’il n’existe pas, en théorie, de bug intrinsèque dans la spécification ou dans le système de types
    Ensuite, dans les langages réels, il est parfaitement normal et attendu qu’il existe des fonctionnalités non vérifiées que l’on suppose utilisées correctement par les humains. Par exemple unsafeCoerce en Haskell ou sun.misc.unsafe en Java
    Le vrai problème, c’est lorsque le système de types se brise même sans utiliser ces fonctionnalités
  • Dire que ça fonctionne est un peu exagéré
    Je n’ai regardé le code que quelques minutes, mais on dirait qu’activer les optimisations le casserait gravement
  • Ils planifiaient et expérimentaient probablement cela depuis des mois
    Avec en plus une grosse suite de tests existante, des outils pour paralléliser les agents et un budget de tokens pratiquement illimité, il ne faut pas non plus se décourager trop vite

• Il y a un livre [0] qui a beaucoup changé ma façon de voir l’attention et les médias
  Le livre lui-même n’est pas extraordinaire, mais il met le doigt sur quelque chose de pertinent ici
  Il existe une énorme asymétrie entre la portée d’une grande annonce spectaculaire, du genre « Bun a été réécrit en quelques semaines en Rust memory-safe », et la portée des rectifications, qu’on retrouve par exemple dans les notes de bas de page d’anciens articles ou au milieu d’issues GitHub
  Cette asymétrie est bien comprise et activement exploitée par l’industrie du marketing et des RP
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Vu l’ambiance actuelle, on a l’impression que beaucoup cherchent n’importe quelle critique du code pour l’amplifier au maximum
    Pour l’instant, cela reste en grande partie assez superficiel
    Fusionner un gros portage assisté par LLM était clairement une décision très audacieuse, mais dans ce que les gens pointent réellement dans le résultat, je ne vois pas grand-chose qui me paraisse pire que dans d’autres portages en cours
    Chaque problème découvert est exagérément monté en épingle
  • Je me demande déjà s’ils ont vraiment prétendu que c’était memory-safe
    Dans toutes les discussions sur ce sujet, il y a des dizaines de commentaires disant que le codebase vibe codé allait exploser sous le poids de blocs unsafe non audités, et que des gens qui semblent ne pas comprendre Rust l’ont relu à la légère
    On a même parfois l’impression qu’ils s’énervent contre l’idée même qu’il faille comprendre un langage de programmation, quel qu’il soit
  • Est-ce que c’est bien le concept exprimé par la citation « un mensonge fait la moitié du tour du monde avant que la vérité ait eu le temps de mettre ses chaussures » ?
  • Pas seulement le marketing et les RP : les médias grand public savent aussi qu’on peut publier d’abord des absurdités puis se rétracter plus tard tout en conservant un effet durable
    Les gens retiennent souvent l’article ou le titre initial, mais ne voient jamais la correction
  • Je pensais plutôt que vous alliez parler du problème dans l’autre sens
    Le portage est encore en cours, il n’y a donc pas eu de grande annonce spectaculaire, et ce n’est ni terminé ni publié
    Ce que je vois, ce sont plutôt des moqueries opportunistes sur du code en cours de développement, ainsi que des tentatives de suggérer que l’équipe aurait dit que c’était terminé ou parfait
    La réécriture n’était qu’une traduction de code destinée à servir de point de départ
    L’équipe de Bun n’a jamais annoncé en fanfare que le code était désormais memory-safe, et elle a toujours clairement dit qu’il s’agissait d’un point de départ
    Exiger qu’il soit immédiatement parfait et qu’il corrige tous les problèmes mémoire du code Zig d’origine, c’est se battre contre une annonce imaginée, pas contre ce que l’équipe Bun a réellement déclaré
    Je me demande aussi si quelqu’un a essayé de faire la correspondance avec les problèmes mémoire existant déjà dans le codebase d’origine

• Ce type d’erreurs était prévisible
  Pour ceux qui ont besoin de stabilité, ils ont laissé la version stable en Zig, et j’imagine que les erreurs finiront par être corrigées

  • Ce type d’erreurs était tout à fait évitable
    L’écosystème Rust dispose d’outils bien connus pour les détecter, et même s’ils n’attrapent pas tous les comportements indéfinis causés par des erreurs dans les blocs unsafe, les exécuter est considéré comme une bonne pratique

• Ce qui m’inquiète le plus, c’est la méta-discussion
  Au départ, j’ai regardé d’un œil critique les mainteneurs qui avaient fermé cette issue GitHub comme hors sujet
  Puis j’ai vu que l’interface GitHub repliait automatiquement en bloc des messages sans aucune valeur informative, qui semblaient venir en masse de forums ou d’un Discord communautaire
  Cela met tout le monde dans une situation perdante
  Si quelqu’un découvre un problème sérieux qui peut légitimement inquiéter une grande partie de la communauté concernée, il a de bonnes raisons de le faire savoir aussi largement que possible
  Il s’agit d’une demande substantielle à propos de changements récents, et le fait de critiquer le ton n’enlève rien à la réalité des faits
  Le problème, c’est qu’un surplus d’attention tue littéralement la discussion
  Du côté des mainteneurs, cela peut aussi servir de bouclier à ceux qui prennent des décisions plus émotionnelles, voire proches d’une psychose liée à l’IA
  Un projet dominé par une mentalité de siège, qui bloque et ignore les critiques, peut très vite dérailler
  À l’inverse, dans un projet qui ne protège pas ses mainteneurs de l’anxiété et des pathologies liées à l’IA, le burnout des mainteneurs devient inévitable

• Cette réécriture de Bun donne l’impression d’un événement potentiellement conçu pour le marketing de Mythos

  • Jusqu’ici, ni l’équipe Bun ni qui que ce soit chez Anthropic n’a fait de marketing excessif en présentant cela comme autre chose qu’un passage vers un langage plus memory-safe avec de meilleures garanties du compilateur
    Le battage médiatique et la publicité autour du sujet proviennent surtout, pour l’instant, des réactions négatives de personnes hostiles à l’IA
    À mon avis, cela est aussi fortement lié à la perception plus négative d’Anthropic elle-même, alimentée par certaines de ses décisions récentes
  • Cela ressemble simplement à un rug pull d’entreprise
    On a l’impression que seuls les besoins d’Anthropic comptent et qu’ils se moquent du reste
  • Ils ont lancé la réécriture avec un budget de tokens dont on ne sait même pas combien d’argent il a coûté
    Ensuite ils fanfaronnent, publient un billet de blog disant « Claude Code a permis à l’équipe Bun de réécrire plus d’un million de lignes de Zig en Rust », et les VC salivent
    Ça échoue à des vérifications de base
    On ne sait pas non plus combien d’argent ils dépensent encore pour laisser Mythos mettre le codebase en pièces
    Puis ils publient un autre billet de blog
    Des escrocs et des naïfs applaudissent et les défendent contre la « foule anti-IA délirante »
    Les VC sont encore plus excités
    Voilà comment on gagne de l’argent
    Et ensuite on en arrive à l’idée qu’il faut aussi supprimer les ingénieurs logiciel

• Il y a déjà des bindings vers un autre langage non sûr dans un codebase écrit dans un langage non sûr, donc je ne comprends pas pourquoi on suppose que cela allait paraître immédiatement parfaitement implémenté