Rewriting Bun in Rust

À retenir

1. Idée-force : la réécriture de langage n'est plus une décision à sens unique. Historiquement, changer le langage d'un projet comme Bun (535 496 lignes de Zig) = ~1 an pour une petite équipe, avec gel des correctifs, de la sécurité et des features — donc irréaliste, donc « on ne le fait jamais ». L'IA agentique transforme cet arbitrage : « What if I spend a week testing if Anthropic's new model can rewrite Bun in Rust? » Résultat : 11 jours.
2. Le « pourquoi Rust » est un argument de boucle de feedback, pas de goût. La classe de bugs dominante (use-after-free, double-free, oublis de free sur chemins d'erreur) vient du mélange mémoire GC (JavaScriptCore) × mémoire manuelle (Zig) — un cas que peu de langages conçoivent. En safe Rust, ce sont des erreurs de compilation + nettoyage automatique (Drop, RAII). « Compiler errors are a better feedback loop than a style guide. » Zig préfère le defer explicite (pas de control-flow caché) ; l'alternative — smart pointers maison — offrait « une pire ergonomie que Rust, sans les garanties ».
3. La contrainte qui rend le pari jouable : une suite de tests indépendante du langage. Les tests de Bun sont écrits en TypeScript → ils ne dépendent pas du langage d'implémentation. Le portage vise le changement de comportement minimal, validé par cette suite (60 624 tests, 1,39 M expect(), 0 test supprimé ou skippé, vérifié à la main). C'est le filet qui autorise à merger 1 M de lignes générées par LLM.
4. Portage mécanique > redesign. Choix explicite : préserver l'architecture Zig, minimiser les changements, laisser la Rust idiomatique pour après le ship de v1.4. « Incremental vs all-at-once ? » → tout d'un coup (comme son portage esbuild Go→Zig d'origine, sans LLM). Le reste « n'est que de la tactique ».
5. Le harnais : ~50 dynamic workflows dans Claude Code, en boucle 11 jours. Pseudocode assumé : while (task = todo.pop()) { result = task(); feedback = await [review(result), review(result)]; apply(feedback) }. Workflows dédiés : générer le guide de portage → porter mécaniquement chaque .zig en .rs → corriger les erreurs de compilation par crate → faire passer les sous-commandes (bun test, bun build) → faire passer toute la suite → refactors/cleanup.
6. La revue adversariale, cœur de la fiabilité. Un second Claude, dans un contexte séparé, qui ne voit QUE le diff (aucun raisonnement de l'implémenteur), sommé de « trouver pourquoi c'est faux ». Ratio 1 implémenteur / 2+ relecteurs adversariaux / 1 fixer ; l'implémenteur ne relit pas, le relecteur n'implémente pas (comme chez les humains, celui qui écrit est biaisé vers le merge). Capte des bugs syntaxiquement identiques mais sémantiquement différents : Box droppé avant un uv_close asynchrone (UAF + double-free) ; timespec négatif via trunc vs floor ; unwrap_or eager qui panique là où unwrap_or_else lazy ne l'aurait pas fait.
7. « Corriger le processus qui génère le code, pas le code à la main. ». Principe directeur : quand un bug ou un anti-pattern apparaît, on édite le workflow/prompt, pas le fichier. Ex. : quand Claude ajoute de longs commentaires pour justifier des workarounds, règle ajoutée pour les relecteurs → « If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code. » Un edit de prompt, quelques heures, le comportement disparaît.
8. Préparation (de-risking) avant d'écrire une ligne. ~3 h de discussion avec Claude → PORTING.md (mapping patterns/types Zig→Rust). Puis un workflow analysant le lifetime de chaque champ de struct (lecture + trace du control-flow, 2 relecteurs adversariaux) sérialisé en LIFETIMES.tsv pour les autres Claude. Puis essai sur 3 fichiers avant de lancer les 1 448.
9. Le parallélisme et ses false starts. Lancer 1 448 fichiers d'un coup → les Claude s'écrasent (git stash/stash pop/reset --hard). Fix : interdire tout git qui ne committe pas un fichier précis, aucun cargo, aucune commande lente. Puis 4 shards / 4 worktrees × 16 Claude = ~64 Claude simultanés. Pic : 1 300 lignes/min, 695 commits/h, 58 commits/min. Un grep lent a gelé le disque faute d'IOPS relevés sur l'instance EC2.
10. ~16 000 erreurs de compilation comme file d'attente. Découpage en ~100 crates (compilation plus rapide) → révèle des dépendances cycliques (le codebase Zig était une seule unité de compilation) → workflows de classification puis de refactor. cargo check écrit les erreurs dans un fichier groupé par crate → réparties sur 64 Claude. Isolation renforcée via systemd-run (cgroups) pour les tests de fuite mémoire / stress (10k process, Go de disque, sockets TCP saturés).
11. La route vers le vert (CI Buildkite, 6 plateformes). De 972 fichiers de test en échec à 23 en 2 jours ; Linux full green ~1 jour avant Windows ; build #54202 = 6/6 plateformes vertes → merge. Merger ≠ release : confiance suffisante pour s'engager, pas encore pour publier.
12. Le coût, chiffré et assumé. Pré-merge : 5,9 Md tokens d'entrée non cachés + 690 M en sortie + 72 Md de lectures de cache ≈ 165 000 $ au prix API. Alternative humaine réaliste : 3 ingénieurs, ~1 an, pendant lequel « on n'aurait pas amélioré la compat Node.js, corrigé de bugs/failles ni livré de features » — donc jamais fait. « The realistic alternative was to do nothing and keep fixing the bugs forever. »
13. Après le merge, le travail continue. 11 rounds de revue de sécurité Claude Code Security ; fuzzing coverage-guided 24/7 de tous les parsers (JS/TS/JSX/CSS/JSON5/TOML/YAML/Markdown/INI/Bun Shell/semver/.patch), 100 Md exécutions → ~15 PRs (le fuzzer envoie le repro à Claude qui soumet la PR, revue humaine). ~4 % de code unsafe (~13 000 unsafe / ~780 000 lignes), dont 78 % sur une seule ligne (pointeur venu du C++ ou appel C) — appelé à baisser vers du Rust idiomatique. 19 régressions connues, toutes corrigées (ex. debug_assert! macro effacée en release → HMR cassé).
14. Le modèle et la production. Pré-version de Claude Fable 5 (« a Mythos-class model ») ; les dynamic workflows de Claude Code ont tenu 64 Claude pendant 11 jours (« sinon j'aurais dû écrire mon propre harnais »). Premier release sur le Bun-en-Rust : Claude Code v2.1.181, +10 % de démarrage sur Linux, changements user-facing minimes → preuve de maturité prod.
15. À relier. revue de code par agents / vérification adversariale et consensus (Monperrus « The End of Code Review », série ADLC de Kent Beck-style « prosecution not code review » / « tests are the spec ») ; Loop/Harness Engineering (Lushbinary, Osmani, OpenAI Codex agent-first, technique Ralph, git worktrees) ; skills & dynamic workflows Claude Code ; Zig déjà au corpus (ZML/LLMD, souveraineté du silicium) ; FinOps des tokens / coût par résultat.