Bun réécrit en Rust : pragmatisme ou aveu d’échec de Zig ?

Bun, le runtime JavaScript qui a soufflé Node.js sur ses propres benchmarks avec des résultats hallucinants, vient d’annoncer quelque chose d’inattendu : une migration progressive de ses composants internes vers Rust. Pour rappel, Bun a été entièrement conçu en Zig — c’était même son identité technique, son argument différenciateur numéro un. Voir l’équipe opérer un tel virage mérite qu’on s’arrête dessus sérieusement.

Ce n’est pas une refonte de zéro du jour au lendemain. L’équipe parle d’une migration incrémentale, composant par composant, en maintenant l’interface externe identique. Mais la direction est claire : Zig sort par la petite porte, Rust entre par la grande. Et quand on connaît les deux langages, ça n’a franchement rien d’une surprise.

La vraie question n’est pas « pourquoi Rust » — on va y venir. C’est plutôt : qu’est-ce que ça dit sur l’état de Zig en tant que langage de production en 2026, et concrètement, qu’est-ce que ça change pour toi qui utilises ou envisages d’utiliser Bun dans tes projets ?

Pourquoi Bun était écrit en Zig — et ce que ça coûtait vraiment

Zig, c’est un langage système créé par Andrew Kelley, pensé comme une alternative moderne à C — sans les pièges de C++, avec un contrôle total sur la mémoire et des performances proches du métal. Jarred Sumner, le créateur de Bun, a misé sur Zig très tôt, à une époque où le langage n’était même pas en version stable. Le pari : aller chercher des performances que Rust ne pouvait pas toujours atteindre, grâce à un contrôle très fin sur l’allocation mémoire et l’absence de certaines abstractions coûteuses.

Et ça a marché, spectaculairement. Les premiers benchmarks de Bun ont stupéfié la communauté JS : 3 à 4 fois plus rapide que Node.js sur certains workloads, démarrage quasi-instantané, consommation mémoire réduite. Zig n’était pas qu’un choix excentrique de fondateur — c’était une décision d’ingénierie réfléchie et audacieuse qui a payé.

Mais Zig a un coût opérationnel réel. Le langage est encore jeune, la toolchain a longtemps été instable, la documentation reste parcellaire, et surtout : recruter des développeurs Zig est un vrai casse-tête. Ce n’est pas une critique du langage en lui-même — c’est la réalité d’un écosystème qui n’a pas encore atteint sa maturité. Quand tu construis un produit qui doit durer, évoluer et s’appuyer sur une équipe qui grandit, ces contraintes finissent par peser lourd dans la balance.

Rust, le choix raisonnable — et « raisonnable » n’est pas une insulte

Rust a maintenant une décennie d’existence derrière lui et un écosystème d’une solidité difficile à contester. Cargo est probablement le meilleur gestionnaire de paquets de l’univers des langages système. Les crates couvrent tout : parsers, runtime async, cryptographie, sérialisation, protocoles réseau. Le tooling est mature, Clippy catch tes erreurs avant toi, et rust-analyzer rend l’expérience de développement bien plus agréable qu’avec Zig aujourd’hui.

En termes de performances brutes, Rust et Zig sont comparables sur la plupart des workloads réels. On parle de différences souvent inférieures à 5% — parfois en faveur de l’un, parfois de l’autre, selon les cas. Ce que tu gagnes en passant à Rust, ce n’est donc pas de la vitesse : c’est de la vélocité de développement, l’accès à des bibliothèques existantes et battle-tested, et une communauté de contributeurs potentiels infiniment plus large.

Pour une structure comme Oven (la société derrière Bun, avec des investisseurs et des salaires à payer), recruter des développeurs capables de maintenir un runtime de cette complexité n’est pas un détail administratif. Avec Rust, le vivier de talents est incomparablement plus profond. Ce virage n’est pas une capitulation sur la performance — c’est de l’ingénierie pragmatique, et il n’y a rien de honteux là-dedans.

Ce que ça change (vraiment) pour les performances

Spoiler : probablement rien de visible pour toi. La performance d’un runtime JS ne dépend pas que du langage dans lequel il est écrit — elle dépend de l’architecture globale, du moteur JS sous-jacent (Bun utilise JavaScriptCore d’Apple, le même que Safari), des algorithmes d’I/O, de la gestion des timers et des événements. Zig versus Rust est un facteur parmi une centaine d’autres.

D’ailleurs, les autres runtimes rapides ne sont pas tous en Zig. Deno utilise Rust depuis le premier jour. Le runtime Workers de Cloudflare tourne sur V8 en C++. JavaScriptCore lui-même est en C++. Les benchmarks impressionnants de Bun sont le résultat de décisions architecturales globales, pas d’un unique choix de langage qu’on pourrait extraire et reproduire ailleurs.

Choisir Zig plutôt que Rust pour les performances, c’est optimiser la dernière ligne droite quand tu n’as pas encore fini de construire le circuit.

Ce qui pourrait réellement s’améliorer avec Rust, c’est la stabilité sous charge et la sécurité mémoire des nouveaux composants. Sur un outil critique utilisé dans des pipelines de build ou dans des applications sur mesure exposées en production, réduire les risques de bugs liés à la gestion mémoire a une valeur concrète — moins d’incidents, moins de nuits à déboguer des segfaults improbables.

La réécriture incrémentale — la seule qui ne finit pas en catastrophe

L’histoire de l’informatique est pavée de réécritures ratées. Le cas d’école : Netscape en 2000, qui a tout jeté pour repartir de zéro sur Mozilla, a mis trois ans à livrer quelque chose d’utilisable, et a quasiment coulé l’entreprise dans l’aventure. La règle de Joel Spolsky — « ne réécris jamais de zéro » — est devenue un mantra dans l’industrie, et elle reste valide.

Mais Bun ne fait pas ça. L’équipe adopte une approche chirurgicale : identifier les composants qui bénéficieraient le plus du passage à Rust (souvent ceux qui ont besoin de bibliothèques Rust déjà existantes et matures), les migrer un par un, en maintenant l’interface externe identique. C’est exactement le pattern « strangler fig » — tu fais croître le nouveau système autour de l’ancien jusqu’à ce que l’ancien disparaisse naturellement.

L’avantage majeur de cette approche : à aucun moment tu ne te retrouves avec un runtime cassé. Les utilisateurs de Bun continuent de recevoir leurs mises à jour, leurs correctifs de sécurité, leurs nouvelles features. La migration est invisible de l’extérieur. C’est probablement la seule façon responsable de mener ce type de transition sur un outil déployé en production par des milliers d’équipes.

Ce que ça dit sur Zig — et sur l’avenir de Bun

Pour l’écosystème Zig, ce signal est un peu amer à avaler. Bun était l’une des success stories les plus visibles du langage — un projet ambitieux, médiatisé, qui prouvait que Zig pouvait être utilisé pour construire des outils critiques et performants. Le voir évoluer vers Rust pose des questions légitimes sur la capacité de Zig à retenir les projets au-delà de la phase de prototype.

Cela dit, Zig reste un projet sérieux avec un futur. La version 0.14 a apporté des stabilisations importantes, le compilateur s’améliore, et la communauté est engagée. Le problème de Zig n’est pas technique — c’est un problème de maturité d’écosystème, et ça prend du temps à construire. Ce que Zig était à Bun en 2022, Rust l’était à Firefox en 2012 : un pari sur un langage pas encore mainstream.

Pour Bun lui-même, ce virage est plutôt un bon signe de santé. Passer de « projet fondateur visionnaire qui va vite » à « produit qui pense à long terme et construit une équipe solide » est une transition normale — et nécessaire pour tout outil qui ambitionne de s’installer dans les stacks de production durables. Si tu gères l’hébergement et la performance de projets web sérieux, la pérennité du runtime que tu utilises n’est pas un détail.

Mon avis tranché sur ce choix

Jarred Sumner a fait quelque chose de difficile : admettre qu’un choix technologique fort, qui a fait le buzz et donné son identité au projet, n’est plus le choix optimal pour la suite. C’est exactement le type de décision que les bons ingénieurs prennent et que les mauvais évitent par fierté ou par peur du narratif. Respect sincère pour ça.

Est-ce que ça marque la fin de Zig comme langage sérieux ? Non. Mais ça confirme que Zig est encore dans une phase où il vaut mieux l’utiliser sur des projets où tu maîtrises entièrement la stack et l’équipe, pas quand tu dois recruter large et itérer vite. Pour les startups et les équipes en croissance qui veulent du langage système — Rust reste le choix le moins risqué en 2026, et probablement pour encore quelques années.

Ce qui m’intéresse vraiment maintenant, c’est de voir si les benchmarks tiennent sur la durée une fois que des parties critiques tournent en Rust. Mon pari : ils tiennent, avec peut-être quelques microsecondes de moins sur les cas synthétiques et aucune différence perceptible en conditions réelles. Et si Bun gagne en stabilité sur des workloads intensifs en échange, le trade-off sera largement gagnant.