Claude Code utilise Bun réécrit en Rust

• À partir de Claude Code v2.1.181, Bun porté en Rust est intégré, ce qui a accéléré de 10 % le démarrage sur Linux, mais la plupart des utilisateurs ne remarquent presque aucun changement
• En inspectant les chaînes de l’exécutable, on peut voir Bun v1.4.0, qui n’a pas encore de tag officiel, ainsi que des chemins vers des fichiers source Rust
• Dans ~/.local/bin/claude, 563 noms de fichiers .rs ont été trouvés, dont src/runtime/bake/dev_server/mod.rs
• Il est aussi possible de vérifier que la version intégrée est bien 1.4.0 en préchargeant un fichier TypeScript avec BUN_OPTIONS pour afficher Bun.version
• La version Rust a été distribuée en tant que build Bun canary et tourne déjà en production sur des millions d’appareils via Claude Code

---

Bun en Rust intégré à Claude Code

• D’après Rewriting Bun in Rust, Claude Code v2.1.181, sorti le 17 juin, utilise le portage Rust
  • Le démarrage sur Linux est 10 % plus rapide
  • En dehors de cela, les utilisateurs ont à peine remarqué de différence, et Jarred Sumner a résumé cela par « Boring is good »
  • Il tourne déjà en production sur des millions d’appareils via Claude Code
• La version de Bun intégrée peut être trouvée dans les chaînes de l’exécutable Claude

strings ~/.local/bin/claude | grep -m1 'Bun v1'

• Dans un environnement macOS arm64, la sortie est Bun v1.4.0 (macOS arm64)
• À ce moment-là, la dernière release stable sur GitHub était Bun v1.3.14, publiée le 12 mai ; cela signifie donc que Claude Code embarque un aperçu de la v1.4.0 qui n’est pas encore officiellement publiée
• La version Rust a été rendue publique sous forme de Bun canary et peut être installée avec bun upgrade --canary

Vérification des sources Rust et de la version

• En extrayant les chemins des sources Rust depuis l’exécutable, on peut confirmer 563 noms de fichiers

strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'

• La liste inclut notamment les chemins suivants

src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs

• La méthode partagée par Ajan Raj consiste à précharger un fichier TypeScript avec BUN_OPTIONS afin d’afficher directement Bun.version intégré à Claude Code

cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version

• Cette commande affiche également 1.4.0
• Dans ce commit du 17 mai, la version de package.json est passée à 1.4.0 et y est restée depuis ; elle n’a pas encore été incluse dans une release taguée autre que canary

[GN⁺]

Réactions sur Hacker News

• Il est difficile de comprendre pourquoi une TUI devrait passer par JavaScript puis s’exécuter dans React pour terminal. Le fait qu’Anthropic ait même acquis un runtime pour améliorer la TUI fait encore plus douter de la qualité de l’ingénierie. Si la réécriture était si facile, il aurait été bien moins coûteux de porter Claude Code vers un langage natif

  • C’est déjà une activité qui fonctionne bien et génère d’énormes revenus, donc la question « pourquoi cette technologie ? » relève davantage d’un choix business que technique. Le choix technologique initial remplit son rôle, donc même si l’architecture n’est pas parfaite, il y a peu de raisons de la changer
    Même pour Bun, une réécriture n’est pas simple, et un outil de développement sans UI, avec des contrats d’API et des tests clairs, est plus facile à juger fiable après réécriture qu’un outil UI aux fonctionnalités floues et aux tests insuffisants
  • En utilisant Claude, OpenCode et Ghostty ensemble, les programmes de terminal interactifs consomment énormément de CPU et de batterie, au point qu’un laptop resté en veille toute la nuit devient chaud. Il existe pourtant plus de 40 ans de précédents avec curses/ncurses, Emacs, Vim, jusqu’à MS-DOS, donc on peut se demander pourquoi forcer l’usage de technologies web
  • J’ai vu un billet disant qu’une entreprise Haskell connue était passée à Python à cause de la vitesse d’itération du développement assisté par LLM. Il existe énormément de données d’entraînement sur React, et le temps de compilation de TypeScript est aussi plus court que celui de Rust, etc.
    Le code orienté utilisateur et les couches UX qui changent vite ont de fortes chances de rester sur des systèmes dynamiques permettant une itération rapide, tandis que les couches d’infrastructure migreront vers des environnements système sûrs comme Rust. Java/C# occupent une zone intermédiaire, mais à l’avenir TypeScript/Python devraient suffire pour l’UX, et Rust sera plus adapté aux tâches système, ce qui pourrait réduire leur place
    https://avi.press/posts/2026-07-10-after-7-years-in-producti...
  • Si l’on considère qu’Anthropic écrit Claude Code avec l’IA, JavaScript n’est pas un mauvais choix. Les données d’entraînement sont abondantes, et cela évite aussi les problèmes de multithreading et de gestion mémoire qui peuvent perturber l’IA dans d’autres langages très performants, ce qui le rend adapté à une production logicielle rapide avec l’IA
  • OpenAI a décidé il y a environ un an de réécrire Codex en Rust. Si une réécriture est vraiment si simple, il faut aussi se demander pourquoi Bun est nécessaire et pourquoi tout le code JavaScript n’est pas migré en Rust
    https://github.com/openai/codex/discussions/1174

• En lisant le texte original de Jarred, il semble clair que la motivation du passage vient du fait que des parties auparavant manuelles en Zig sont automatisées en Rust. Les humains comme les agents étant non déterministes, suivre manuellement la durée de vie mémoire et la libération explicite en Zig laisse s’accumuler longtemps des bugs d’omission, alors que Rust élimine cette classe d’erreurs, ce qui en fait un bon compromis du point de vue de la gestion de l’ingénierie
  En particulier, les erreurs du compilateur constituent un garde-fou déterministe nécessaire pour les agents de code, et si l’on donne à Claude un moyen d’évaluer l’exactitude et l’objectif de « faire en sorte que ça compile », cela fonctionne bien. Une approche généralisée consistant à transformer des sorties probabilistes en garanties solides par des tests déterministes est résumée ici : https://michael.roth.rocks/blog/verification-surface/

  • Zig et C ne sont pas adaptés quand on crée beaucoup de petites allocations dont les durées de vie sont indépendantes les unes des autres. Pour les utiliser de manière robuste, il faut gérer directement les durées de vie, par exemple en regroupant les allocations dans des arènes ou en utilisant des buffers fixes
    Dans ce cas, Zig peut être aussi robuste que Rust, mais si l’on veut des schémas d’allocation de style langage managé, comme les préfère un LLM, Zig n’est pas adapté
  • Ce sont les langages à garbage collection qui automatisent cela. En Rust aussi, il faut réfléchir et suivre la durée de vie mémoire, mais le borrow checker empêche les mauvais traitements et fournit un retour de correction immédiat, ce qui le rend adapté à l’écriture par LLM. Les paramètres de référence immuable par défaut évitent aussi de gros problèmes de performance
  • Bun contient actuellement beaucoup de Rust unsafe, donc on peut douter qu’il élimine automatiquement des classes d’erreurs : https://news.ycombinator.com/item?id=48967630
  • D’après mon expérience, les LLM détectent assez facilement les bugs mémoire. Tout cela ressemble surtout à un événement marketing réussi pour Anthropic
  • Si je me souviens bien, cette réécriture en Rust était entièrement en unsafe, donc il est probable qu’elle n’élimine pas automatiquement ce problème

• Indépendamment de l’avis de Jarred ou de Simon Willison, je vois cette affaire de manière assez négative. Plus que le rachat de Bun par Anthropic ou la réécriture par IA, le vrai problème est la façon immature dont cela a été mené, en partant de l’attitude « ce n’est que ma branche et vous sur-réagissez » pour fusionner en moins d’un mois une PR de plus d’un million de lignes
  La communication a été très mauvaise, cela a sapé la confiance et accentué les divisions, et on peut se demander s’il était vraiment si difficile de suivre l’approche adoptée par l’équipe TypeScript pour la 7.0

  • Au final, la plupart des utilisateurs de Claude Code ne l’ont probablement pas remarqué ou s’en moquent, et ceux qui y voient un problème sont peut-être une infime minorité, donc cela n’a peut-être pas d’importance en pratique
  • TS7 aussi est un cas représentatif où l’on a porté ligne par ligne vers un autre langage plutôt que de reconsidérer sérieusement l’architecture

• Le Bun v1.4.0 inclus dans Claude semble être une version preview non encore publiée. Si c’est le cas, le projet FOSS Bun semble s’être discrètement transformé en autre chose, donc c’est une bonne chose que je me sois contenté de laisser l’enquête en TODO sans l’adopter
  Je ne trouve pas de document de gouvernance pour Bun, et je me demande si, en pratique, Anthropic décide désormais de tout le travail et de ce qui est fusionné ou non

  • Il est difficile de comprendre la conclusion selon laquelle passer à Rust tuerait le projet
  • La PR est publique, donc n’importe qui peut la compiler et l’utiliser, et l’équipe Anthropic a simplement décidé de l’utiliser en premier
  • De ce que je comprends, en pratique tout dépend de la volonté de Jarred de l’accepter cette semaine-là. L’historique des changements de Claude Code mentionnait déjà presque un mois plus tôt le passage à Bun 1.4.0, mais comme ce journal avait été rédigé par IA, il n’est pas étonnant que la plupart des gens ne l’aient pas lu
  • J’ai moi aussi étudié l’adoption de Bun puis décidé de ne pas l’utiliser à cause de son instabilité, et à voir cette affaire, cela semble avoir été le bon choix

• Je ne vois pas pourquoi ils ont autant compliqué les choses autour de Bun. Si l’agent peut porter Zig vers Rust, Claude Code aurait aussi pu être réécrit directement en Rust depuis JavaScript pour supprimer la dépendance au runtime et améliorer les performances

  • Il n’y a aucune raison d’être confus si l’on considère que la réécriture de Bun en Rust n’a pratiquement rien à voir avec la stratégie produit d’Anthropic
  • Si l’on ne considère que Claude Code, une réécriture directe en Rust aurait sans doute été meilleure, mais cela aurait fortement réduit la valeur de l’acquisition de Bun/oven.sh
    Bun aura des utilisateurs externes et internes à Anthropic au-delà de Claude Code, et permet d’obtenir un runtime JavaScript et un écosystème d’outils susceptibles de plaire aux modèles de code. À l’avenir, Anthropic pourrait même fournir un cloud spécialisé dans l’exécution et la gestion de ce type d’apps, et le simple fait de capter une communauté de développeurs lui donnerait une influence bien plus grande que de porter seulement Claude Code en Rust
  • On peut aussi se demander si Claude Code est réellement limité par les performances. Les runtimes JavaScript ont un vaste écosystème d’outils et facilitent le développement de plugins, ce qui les rend tout à fait adaptés

• En laissant de côté les suppositions et les réactions émotionnelles, c’est la qualité d’exécution réelle qui m’intéresse. Il faut vérifier non seulement la vitesse de démarrage, mais aussi l’usage de RAM et de CPU, ainsi que le comportement face aux boucles infinies ou aux interblocages ; si c’est identique ou meilleur qu’avant, ce serait très impressionnant
  En tant que développeur, je n’aime pas l’idée que l’IA puisse prendre des emplois, mais si n’importe qui pouvait créer le logiciel qu’il veut à partir d’une simple demande, cela pourrait améliorer le monde. Si l’on déteste la collecte de données de Microsoft, on pourrait faire créer un système d’exploitation par une IA ; si l’on déteste l’écoute de Google, un téléphone ; une forme d’autosuffisance technique pourrait devenir possible, et face à cela la stabilité de l’emploi individuel paraîtrait secondaire
  C’est pourquoi il est encore plus important de garder la technologie open source ; sinon, on ne fera que reproduire les structures monopolistiques existantes tout en perdant des emplois

  • La partie la plus difficile du développement logiciel est d’obtenir des exigences claires. Même avec une AGI parfaite, les gens n’arrivent pas à exprimer clairement ce qu’ils veulent, donc un monde où chacun obtient exactement le logiciel qu’il souhaite n’adviendra probablement pas
  • Même un bon outil doit être utilisé par un artisan expérimenté pour produire d’excellents résultats. Les bons développeurs savent poser les bonnes questions, mettre en place des garde-fous et ajuster eux-mêmes le résultat là où c’est nécessaire
  • Qualifier de démocratisation technologique des modèles fermés cachés derrière un paywall subventionné est d’une naïveté excessive. La stratégie consistant à utiliser surtout le portage de Bun vers Rust à des fins marketing semble avoir bien fonctionné

• Récemment, en utilisant Claude Code dans un onglet Kitty, j’ai subi une erreur de segmentation, après quoi l’onglet entier ne répondait plus aux entrées. Un lien de signalement apparaît, mais on ne peut pas cliquer dessus, et il est encodé, donc impossible de vérifier quelles informations sont envoyées

  • Bun est de loin meilleur que les autres runtimes JavaScript en matière d’idées et de fonctionnalités, mais sa stabilité est désastreuse, et j’ai eu environ 20 fois plus d’erreurs de segmentation qu’avec Node. Ce chiffre se base sur les données de télémétrie de New Relic
  • Si Segmentation fault ne s’est pas affiché dans le shell, il est probable qu’il ne s’agisse pas d’une erreur de segmentation mais d’un blocage. Si c’était bien une vraie erreur, on peut restaurer l’onglet en revenant au shell puis en tapant reset, même si rien n’apparaît à l’écran
  • J’utilise Ghostty et Claude Code sur mon MacBook professionnel, mais je n’ai pas encore rencontré ce problème. Avant, le système se figeait à cause d’une fuite mémoire incontrôlée et je devais redémarrer, mais cela a disparu ces dernières semaines ; il est trop tôt pour l’affirmer, mais il est possible que le portage en Rust ait réduit les fuites mémoire
  • Dans Ghostty, j’observe un blocage similaire quand j’utilise l’interface de questions interactives de Claude : hormis le défilement, aucune entrée n’est acceptée, y compris la sélection ou l’annulation. Je ne pense toutefois pas que cela soit lié à Bun
  • La version Zig avait déjà des erreurs de segmentation, et si cela a été porté ligne par ligne en unsafe Rust, alors le code à l’origine du problème est resté tel quel. Cela ne sera probablement pas résolu avant une refactorisation en Rust idiomatique et sûr en mémoire

• Ils donnent l’impression d’être des ingénieurs ayant très bien réussi mais médiocres, capables de bien décrire les problèmes et disposant d’un budget de tokens illimité. S’ils payaient eux-mêmes le coût des tokens, ils auraient une incitation financière à améliorer l’efficacité logicielle
  La réalité cachée des centres de données IA, c’est que même avec une efficacité de cluster GPU de seulement 40 à 60 %, on compense en achetant plus de matériel grâce à l’argent disponible. S’ils craignent les concurrents chinois, c’est peut-être parce qu’eux n’ont pas le luxe d’un tel gaspillage

• Ce travail est un transpilage, et de mauvaise qualité en plus. Le code généré est très loin d’un Rust idiomatique, au point qu’on peut le qualifier de monstrueux

  • Cela semble quand même fonctionner correctement. Pour l’instant, il s’agit essentiellement d’une première étape de portage mécanique ligne par ligne, et l’étape suivante doit consister à le retravailler en Rust idiomatique ; continuer à parier contre cette réécriture ne paraît donc pas très judicieux
  • En termes de stabilité, d’efficacité et de coût, il aurait été bien plus raisonnable d’utiliser ou d’écrire un convertisseur inter-langages qui préserve autant que possible la structure d’origine
    En général, une réécriture permet d’intégrer les leçons tirées du codebase existant, mais avec un portage fichier par fichier par agent, cet avantage disparaît. Dans tous les cas, on obtient une traduction non idiomatique, mais l’usage d’un LLM y ajoute encore la non-déterminisme et un coût énorme
  • Il faudrait des exemples concrets de ce code Rust qualifié de monstrueux
  • Je me demande pourquoi ils n’ont pas plutôt transpilé directement vers LLVM IR
  • Si le projet atteint son objectif de sûreté mémoire, on peut se demander si le caractère idiomatique du code a vraiment tant d’importance

• Dernièrement, Claude Code est bien plus instable qu’avant, et des erreurs de rendu TUI corrompent souvent l’historique de conversation

  • J’utilise Claude à contrecœur depuis février, et dès le départ c’était le pire TUI que j’aie utilisé jusqu’ici, avec des défauts de rendu, des erreurs de saisie clavier, etc. Pourtant, au cours de la semaine passée, c’est encore devenu pire, au point d’abîmer même les sessions terminal, par exemple quand une partie des caractères saisis ne s’affiche pas
    On peut corriger cela en le mettant en arrière-plan, en exécutant reset, puis en le ramenant au premier plan. J’ai demandé un diagnostic à Claude : il a répondu qu’il n’avait pas ce bug et que cela venait d’un autre programme, alors que seuls tmux et Claude tournaient. Si la version Rust a été déployée récemment, cela correspond à peu près au moment où la qualité a commencé à se dégrader
  • Sous Windows, chaque redimensionnement de fenêtre corrompt complètement l’affichage, au point qu’il faut redemander la réponse qui vient d’être donnée. Ce n’est pas un problème nouveau, mais j’ai l’impression que c’est pire récemment
  • Je ne suis pas opposé à l’IA en soi, mais Anthropic va trop loin et publie du code de mauvaise qualité généré par IA. De vrais ingénieurs devraient continuer à intervenir pour piloter l’outil, mais Anthropic semble vouloir confier 100 % du code à l’IA