Ladybird adopte Rust et accélère la transition avec l’aide de l’IA

• Le projet de navigateur Ladybird adopte Rust comme langage à sûreté mémoire pour remplacer le C++, et utilise des outils d’IA dans le processus de transition
• Swift avait d’abord été envisagé, mais le projet s’est tourné vers Rust en raison de limites d’interopérabilité avec le C++ et de contraintes de plateforme
• La première cible du portage est LibJS, le moteur JavaScript, avec une traduction manuellement pilotée au moyen de centaines de prompts via Claude Code et Codex
• Environ 25�00 lignes de code Rust ont été produites en à peine deux semaines, et il a été vérifié que la sortie comme les performances sont strictement identiques à la version C++
• Le projet conservera pour l’instant un développement parallèle en C++ et en Rust, avec l’objectif à long terme de renforcer la sûreté et la maintenabilité

---

Pourquoi adopter Rust

• Ladybird a étudié plusieurs langages afin de trouver un langage à sûreté mémoire pour remplacer le C++
  • Swift a été écarté en raison du manque d’interopérabilité avec le C++ et des limites de prise en charge hors de l’écosystème Apple
• Rust a été évalué comme un langage doté d’un écosystème mature pour la programmation système, et déjà familier à une grande partie des contributeurs
• En 2024, son adoption avait été reportée à cause de la mauvaise adéquation de Rust avec l’OOP de style C++, mais la décision a ensuite été réintroduite au nom de la sûreté et de la maturité de l’écosystème
• En s’appuyant sur les précédents de Firefox et Chromium, l’équipe a jugé que Rust convenait aussi à Ladybird

Processus de portage de LibJS

• La première cible de la transition est LibJS, le moteur JavaScript de Ladybird
  • Avec ses composants indépendants comme le lexer, parser, AST, bytecode generator et sa couverture de tests basée sur test262, il constituait un bon point de départ
• Le portage a utilisé Claude Code et OpenAI Codex
  • Il ne s’agit pas d’une génération automatique, mais d’une traduction pilotée par des humains, avec choix direct de l’ordre de portage et de la structure du code
  • Des instructions détaillées ont été données via des centaines de prompts, puis la validation du code et la détection d’erreurs ont été effectuées à l’aide de différents modèles

Résultats et validation

• L’objectif était que les sorties des pipelines C++ et Rust soient identiques octet par octet
• Environ 25�00 lignes de code Rust ont été finalisées en deux semaines, raccourcissant un travail qui aurait pris plusieurs mois
• L’AST et le bytecode sont strictement identiques, sans aucune baisse de performance sur les tests et benchmarks JS
• La concordance des résultats pendant la navigation web a été vérifiée via des tests en lockstep exécutant simultanément les pipelines C++ et Rust
• Le code actuel conserve une forme traduite depuis le C++ et reproduit même les schémas d’allocation de registres
  • La priorité absolue est en effet de garantir la compatibilité avec le pipeline C++
  • Lorsque viendra le moment d’abandonner le pipeline C++, le code Rust sera simplifié et nettoyé

Suite du projet

• La transition vers Rust avance comme un travail parallèle, et non comme l’axe principal de développement du projet
• Le code C++ et le code Rust coexisteront, avec des frontières d’interopérabilité clairement définies
• L’ordre et le périmètre du portage sont pilotés par l’équipe principale, et les contributeurs externes doivent se coordonner au préalable
• À long terme, le projet vise une amélioration progressive de la sûreté et de la maintenabilité
• Tout en reconnaissant que cette décision peut être controversée, l’équipe l’évalue comme le bon choix pour l’avenir de Ladybird

[GN⁺]

Avis Hacker News

• Le point le plus intelligent de ce projet est d’avoir exigé une sortie strictement identique au byte près
  Grâce à cela, ils peuvent exécuter l’ancien et le nouveau pipeline en parallèle, comparer les diff et repérer immédiatement les bugs introduits pendant la traduction
  Si tant de réécritures échouent, c’est parce que les gens essaient de « l’améliorer » pendant le portage et finissent par traquer des bugs fantômes dus à l’ancienne version, à la nouvelle version, ou simplement à des différences de comportement
  Même si la version traduite de C++ vers Rust paraît maladroite au début, ce n’est pas grave. Une fois la partie C++ complètement retirée, on pourra la rendre progressivement plus idiomatic

  • Un portage est un bon moment pour améliorer beaucoup de choses, mais pas pour ajouter de nouvelles fonctionnalités
    Tant que la sortie reste identique, on peut faire du refactoring, de l’optimisation et de la documentation
    Je pense que documenter le code pendant qu’on le lit est le meilleur moment pour le faire. Pour un projet populaire comme Ladybird, mieux documenter revient directement à accélérer le développement
  • J’aimerais voir plus de portages purs faits de cette manière
    Avant, comme le coût d’une migration était trop élevé, on se disait « tant qu’à faire, améliorons aussi », mais au final on passait surtout plus de temps à courir après des bugs fantômes
  • J’aime beaucoup cette approche. Il y a quelques jours, j’ai lu un billet écrit sous l’angle des tests et de la validation, et ça me surprend de la voir appliquée à un projet aussi complexe
  • J’ai moi-même converti des frameworks web plusieurs fois comme ça. J’ajustais le nouveau code jusqu’à ce que la chaîne de sortie HTTP corresponde exactement, puis je supprimais totalement l’ancienne version
  • Avec une bonne suite de tests, cette approche fonctionne encore mieux. J’imagine que c’est aussi le cas pour Ladybird

• Ils ont utilisé Claude Code et Codex pour traduire le code C++ en Rust
  Ce n’était pas entièrement automatique : des humains ont piloté l’ensemble et affiné le résultat avec des centaines de petits prompts
  Ils ont imposé dès le départ que la sortie des deux pipelines soit strictement identique au byte près, et au final 25 000 lignes de code Rust ont été produites en deux semaines
  L’AST et le bytecode correspondaient tous les deux, avec zéro régression
  Je pense que c’est exactement la bonne manière d’utiliser l’IA pour des portages entre langages

  • J’ai moi aussi déjà utilisé Claude pour porter un vieux script Perl cassé vers Rust
    En 80 minutes, il a analysé la structure de Drupal, restauré le design initial et l’architecture des modules à l’identique, et implémenté jusqu’aux plugins personnalisés
    On raconte maintenant que ce site a ensuite été migré vers WordPress, ProcessWire, Node.js, puis désormais jusqu’à Next.js
  • Je trouve dommage que les entreprises d’IA ne se concentrent pas davantage sur ce type d’usage collaboratif
    Je ne veux pas d’un « code fini en un seul prompt », mais d’un outil qui augmente l’intelligence humaine (IA) au fil de longues sessions de va-et-vient avec l’IA
    Mais ce type d’outil ne peut être utilisé que par des gens qui ont déjà des connaissances en développement, donc le marché sera sans doute plus petit
  • Moi aussi, en apprenant Rust, j’utilise avec Claude une compétence appelée « teach »
    Claude n’écrit pas directement le code : il donne seulement des indices et fait la revue
    Rust est difficile à écrire de manière improvisée à cause des caractéristiques du langage, donc cette façon de faire me satisfait beaucoup
  • J’utilise aussi Claude de cette manière. Pas comme un « l’IA fait tout », mais comme un partenaire pour la conception, la revue et les tests
  • J’ai autrefois porté avec Claude un script bash complexe vers golang, et les gains en vitesse et en stabilité ont été énormes
    Il en existe maintenant même une version wasm qui tourne dans le navigateur
    Je n’ai pas implémenté moi-même les parties liées au chiffrement, donc pas d’inquiétude là-dessus

• La transition vers Rust est intéressante, mais c’est surprenant parce que l’équipe Ladybird avait auparavant une position assez marquée de « anti-Rust hype »
  Cela dit, si le projet passe à Rust, il me sera sans doute bien plus facile d’y contribuer

  • J’aime aussi Rust, mais l’enthousiasme excessif autour du langage peut parfois être fatigant
    Un langage n’est qu’un outil, et je ne pense pas qu’il faille lier son identité à un langage particulier
  • Je n’aime pas Rust, mais il y a des cas où c’est le meilleur choix pragmatique
  • Il y a un lien expliquant que Ladybird n’est plus désormais centré sur C++/Swift
  • Le fait que l’orientation linguistique change souvent me met un peu mal à l’aise. Ça peut fragiliser la continuité du projet

• Andreas est un excellent ingénieur avec un vrai sens entrepreneurial
  Je trouve impressionnant qu’il ait fait évoluer un projet hobby vers un projet industriel
  En revanche, ce genre de changement de langage rapide me rend un peu nerveux

  • Andreas n’est pas juste un homme d’affaires, c’est aussi l’ingénieur qui a construit Serenity OS presque seul pendant des années
    Je vois cela comme le résultat d’une croissance naturelle du projet
  • Il a aussi expliqué que le choix de Swift était un jugement rationnel après avoir expérimenté lui-même plusieurs langages
  • Pour rappel, il a autrefois travaillé dans l’équipe du moteur Apple Safari
  • Malgré cela, je me demande toujours si tout cela mènera réellement à un nouveau navigateur
  • Tu dis que ça te rend « nerveux », mais j’aimerais savoir plus précisément ce qui t’inquiète

• La phrase « code Rust non idiomatique qu’on nettoiera plus tard » donne l’impression d’annoncer une autre réécriture, ce qui m’inquiète
  Quand une startup change de langage, cela ressemble souvent à un signal de risque

  • Cela dit, C++ et Rust sont tous deux des langages multi-paradigmes, donc on peut conserver une structure assez similaire pendant le portage
  • Ça me rappelle le « piège de la réécriture » évoqué par Joel on Software
    Quand le développement de la nouvelle version et celui des fonctionnalités existantes avancent en parallèle, il y a une course à la vitesse, et la nouvelle version peut ne jamais rattraper l’ancienne
  • Mais Ladybird n’est pas une startup, c’est un projet open source, donc la comparaison est différente
    Linux, PHP et musl libc ont eux aussi connu plusieurs réécritures complètes
  • Moi, dans une situation pareille, je continuerais simplement à utiliser Firefox
  • Passer plusieurs semaines à faire un portage avec un LLM me paraît un choix un peu étrange

• Maintenant que l’IA s’est généralisée, le calcul autour d’une « réécriture complète dans un nouveau langage » a totalement changé
  Surtout si on dispose d’une suite de tests, le risque diminue énormément
  On vit à une époque où l’importance des tests a été multipliée par dix

  • J’ai moi aussi créé avec l’IA une bibliothèque CLI Python pour un projet personnel
    Pouvoir essayer rapidement différentes interfaces comme Streamlit, Shiny ou Dash rend le prototypage très agréable
  • À long terme, avec les progrès de l’IA, l’importance des langages de programmation eux-mêmes va probablement diminuer
    Sur certains projets, une combinaison low-code + agent suffit déjà largement

• La partie disant qu’ils ont confié la revue de code à l’IA me semble inquiétante
  Les modèles ont des limites pour repérer des erreurs logiques

  • Malgré tout, s’ils ont obtenu au final zéro régression + une sortie identique sur 65 000 tests, on ne peut pas l’écarter complètement
    La vraie question est surtout de savoir si le « nettoyage » annoncé sera réellement fait ensuite
  • Les relecteurs humains non plus ne sont pas parfaits. En faisant relire sous plusieurs angles, que ce soit par l’IA ou par des humains, on peut détecter des erreurs différentes
  • C’est justement un domaine qui doit être validé par la suite de tests
  • Mais certains n’ont aucune envie de maintenir du code Rust non idiomatique généré par l’IA
    Plus on dépend de code produit par l’IA, plus on risque d’entrer dans un cercle vicieux de dépendance à l’IA

• Le fait que le projet développe en parallèle C++ et Rust paraît inefficace
  Je me demande s’il ne vaudrait pas mieux unifier directement sur un seul langage memory-safe

  • Pourtant, comme Firefox, une base de code mixte reste tout à fait possible
    Tant que chaque composant est écrit dans un seul langage, il n’y a pas de problème
  • Si on tente une transition totale d’un seul coup, la perte de momentum peut être si forte que le projet s’arrête
  • On peut aussi obtenir de la sûreté mémoire en utilisant un sous-ensemble strict de C++

• Lors de l’adoption de Swift en 2024, Andreas avait tweeté à propos de Rust
  Il disait que Rust était excellent pour les programmes de courte durée, mais malcommode pour les programmes de longue durée qui maintiennent des graphes d’objets complexes
  Il ajoutait aussi que la communauté avait une réputation toxique
  Lien vers le tweet concerné

  • A-t-il changé d’avis ? Je ne sais même pas s’il fallait remplacer C++ dès le départ
  • Je comprends le sentiment d’une atmosphère exclusive dans la communauté Rust
  • C’est peut-être aussi une transition vers Rust pilotée par l’IA sous pression des sponsors

• Je me demande si ce code Rust non idiomatique ne risque pas de devenir plus tard de la dette technique

  • Le risque principal se situe surtout dans la phase de nettoyage. Des schémas de pointeurs issus de C++ peuvent entrer en conflit avec les règles de possession de Rust
    Le projet Servo a lui aussi rencontré ce problème, mais cela a aussi permis d’identifier des bugs potentiels au passage
  • Le problème n’était pas le C++ en soi, mais le fait qu’ils aient migré vers Rust pour des raisons de sûreté mémoire
  • Andreas évoquait depuis longtemps les problèmes de sécurité GC dans le runtime JS et voulait un langage plus sûr
    Le passage à Rust semble correspondre à ce principe comme un choix mûri