Bun (runtime JS) est en cours de portage « vibe » de Zig vers Rust

 (github.com/oven-sh)
2 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Jarred Sumner, le créateur de Bun, a rendu publique une expérience de conversion de langage à grande échelle avec des agents IA en commitant un guide de portage Zig → Rust (PORTING.md) sur la branche claude/phase-a-port
  • Le portage est divisé en Phase A (traduction préliminaire de la logique fichier par fichier, compilation non requise) et Phase B (passage de la compilation crate par crate), avec une méthode consistant à fournir au LLM environ 300 règles de mapping de types et d’idiomes
  • Sumner lui-même a déclaré sur Hacker News que « il n’est pas décidé de réécrire, et il est fort probable que tout ce code soit abandonné », ce qui place pour l’instant le projet au stade de l’exploration expérimentale
  • Dans la communauté, sont évoqués comme contexte le conflit avec la politique de Zig interdisant les contributions IA après le rachat par Anthropic, le fait que Bun fonctionne déjà sur un fork de Zig, ainsi que les avantages de sûreté de l’écosystème Rust
  • La plupart des PR sont générées automatiquement par @robobun (bot IA), puis relues par CodeRabbitAI et Claude, ce qui en fait un cas montrant à la fois les possibilités concrètes et les limites d’une migration de code à grande échelle pilotée par l’IA

Structure clé du guide de portage (PORTING.md)

  • Le but du portage est de convertir un fichier Zig en fichier .rs dans le même répertoire ; en Phase A, l’objectif est une reproduction fidèle de la logique, indépendamment de la compilation
  • Utilisation interdite de crates externes asynchrones et d’I/O comme tokio, rayon, hyper, async-trait, std::fs, std::net — Bun possède sa propre boucle d’événements et ses propres appels système
  • async fn interdit ; tout le traitement asynchrone conserve, comme en Zig, une approche callbacks + machine à états
  • Les parties incertaines sont marquées avec // TODO(port):, et les idiomes Zig liés aux performances avec // PERF(port): pour traitement en Phase B

Règles de mapping des types et idiomes

  • Fourniture de plus de 50 tables de mapping de types telles que []const u8 → &[u8] (jamais &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
  • defer x.deinit() → suppression puis remplacement par impl Drop, errdefer → utilisation de scopeguard, comptime → conversion en const generic, const fn ou macro_rules!
  • Principe de traitement des chaînes basé sur les octets : interdiction d’utiliser std::string::String ou &str, au profit de &[u8] / Vec<u8> — Bun gère WTF-8 et des octets arbitraires
  • @intCast → T::try_from(x).unwrap() (toujours vérifié), @truncate → x as T (wrapping intentionnel), @bitCast → transmute : correspondances Rust pour les fonctions intégrées de Zig

Carte des crates et modèle de propriété

  • Les espaces de noms Zig comme @import("bun").X sont mappés en 1:1 vers environ 30 crates Rust comme bun_str, bun_sys, bun_jsc, bun_alloc
  • Les crates AST/parser conservent l’arena bumpalo::Bump, tandis que les autres crates utilisent un allocateur global mimalloc, ce qui supprime les paramètres d’allocateur
  • Mapping de propriété des pointeurs : bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>

Réactions de la communauté (Lobsters·HN)

  • De nombreux avis s’interrogent : « S’agit-il vraiment d’un passage à Rust, ou d’une vitrine pour les LLM d’Anthropic ? »
  • Spéculation sur un possible contexte de conflit entre la politique de Zig interdisant les contributions IA et le workflow de développement centré sur l’IA d’Anthropic, tout en reconnaissant que cela relève aussi en partie de la théorie
  • Scepticisme sur la capacité d’un LLM à suivre fidèlement environ 300 règles — avec en parallèle une évaluation positive : « ~16k tokens, c’est une taille adaptée pour des sous-agents »
  • Observation intéressante : l’approche consistant à produire d’abord du code qui ne compile pas en Phase A est à l’opposé des usages habituels des agents de codage
  • Sont aussi cités comme motivations possibles la charge de maintenance du fork Zig de Bun, les breaking changes fréquents de Zig, et le risque de dépendre pour un produit clé d’un langage encore en bêta

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • Pour info, voici ce que Jarred Sumner a dit à ce sujet sur HN : il travaille sur Bun, c’est sa branche, et selon lui ce fil est une surréaction à du code qui ne fonctionne pas
    Il n’a pas encore été décidé de faire une réécriture, et il est même très probable que tout ce code soit abandonné
    L’idée est de voir à quoi ressemble une version qui fonctionne, quelles sont ses performances, à quel point il est difficile de lui faire passer la suite de tests de Bun et de la rendre maintenable, et de comparer côte à côte des versions Rust et Zig viables

    • Ça me rappelle la phrase : « un mensonge fait la moitié du tour du monde pendant que la vérité met ses chaussures »
      Les interprétations technologiques façon culture populaire reposent souvent sur des réactions immédiates

  • Même les pull requests ordinaires de Bun sont assez chaotiques : https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    La plupart sont créées de manière autonome par @robobun, qui vérifie via des actions GitHub si elles font doublon (sur base de Claude), et @coderabbitai ainsi que @claude les relisent
    Pendant ce temps, la CI est cassée, et @robobun finit par fermer certaines de ses propres PR parce qu’elles feraient doublon avec d’autres PR qu’il a lui-même ouvertes
    Les merges dans main sont encore faits par des humains

    • Je ne m’y attendais pas
      Dans mon souvenir, Bun était salué pour l’obsession de la performance de Jarred, donc je ne pensais pas qu’ils laisseraient les LLM semer un tel chaos dans la codebase

  • C’est absurde
    Quand on regarde le « mappage des idiomes », il y a du unsafe partout, et on dirait qu’on va se retrouver avec énormément de code peu idiomatique en Rust
    Le mapping de @fieldParentPtr("field", ptr) a l’air particulièrement brutal
    Cela dit, la « phase A » semble en pratique être une traduction quasi ligne par ligne, puis ils comptent apparemment refactoriser ensuite via des prompts vers un Rust plus idiomatique et plus maintenable
    Le problème, c’est que la conception d’un langage peut fortement orienter l’implémentation — et c’est effectivement le cas — donc il y a un gros risque de créer des nœuds difficiles à démêler plus tard
    Au final, une réécriture manuelle à l’ancienne aurait sans doute été une meilleure voie

    • Transformer ça en code idiomatique et sûr, c’est peut-être justement ce que le LLM fera à l’étape suivante
      Surtout avec les moyens financiers d’Anthropic : l’avantage de l’IA, c’est qu’elle ne se fatigue pas à refactoriser le même code encore et encore

  • Indépendamment de la migration elle-même, la méthode qu’ils ont choisie est particulièrement intéressante
    Le docs/PORTING.md lié contient environ 300 règles de portage, et ça semble trop pour qu’un LLM les « garde toutes en tête » et les suive fidèlement
    Puisqu’Anthropic possède Bun, ce portage dispose en pratique d’un budget de tokens quasi illimité, donc ils pourraient peut-être lancer nombre de fichiers * nombre de règles agents pour essayer de “garantir” que tout est respecté
    Ils divisent aussi le portage en deux étapes : A consiste à porter grossièrement chaque fichier de façon isolée, en s’attendant à ce que la compilation casse, puis B consiste à tout raccorder pour que l’ensemble compile
    En phase A, ils disent aux agents que le code « n’a pas besoin de compiler » et leur demandent de noter chaque fichier porté selon la qualité de sortie : faible / moyenne / élevée
    Faible signifie que la logique est erronée, moyenne que la logique est correcte mais que ça ne compile pas, élevée que la logique est correcte et que ça devrait compiler
    C’est exactement l’inverse de la manière dont moi je comprends et j’utilise les agents de code, donc je suis curieux de voir le résultat
    Intuitivement, si on dit que ça n’a pas besoin de compiler sans donner d’“objectif de fin” clair, le résultat devient très imprévisible, et on risque de se retrouver en phase B à devoir relire une montagne de code peu fiable
    J’ai fait un grep rapide : sur 1 279 scores de qualité de sortie de ce type, environ 3 % étaient faibles, 80 % moyens et 17 % élevés

    • En mai 2026, 300 règles me semblent tout à fait raisonnables
      PORTING.md fait environ 16k tokens et reste concentré sur la tâche principale
      Pour de nouveaux sous-agents, ce n’est pas mauvais, et c’est peut-être même idéal

  • Je me demande s’ils veulent vraiment passer à Rust, ou si c’est surtout un test de LLM d’Anthropic

  • Ça a l’air assez intéressant
    Le volume de règles à traiter d’un coup semble impossible à valider sans passer par un cycle de revue de code énorme
    Il y aura peut-être beaucoup de tokens, mais après ce genre de transformation, j’ai l’impression qu’il deviendra très difficile de réellement vérifier le code
    Si les tests doivent eux aussi passer par le même processus, on peut se demander ce qu’il reste alors comme source de vérité
    Cela dit, en tant qu’expérience, c’est impressionnant

  • Quand on regarde ce que deviennent les tueurs de Node.js, Deno a apporté des améliorations modestes comme un système de permissions ou la prise en charge native de TypeScript, mais n’a pas bouleversé le monde, et ces fonctionnalités sont même en train d’être réimportées dans Node.js
    À l’usage, l’expérience développeur ne m’a pas semblé significativement meilleure, et elle pouvait même être pire à cause d’excellents outils comme pnpm
    C’est peut-être plus rapide, mais sur mes usages de ces 5 à 6 dernières années, je n’ai pas vraiment ressenti de problème de performance avec Node.js
    JSR non plus n’a pas bouleversé le monde, et la communauté a plutôt créé npmx, qui offre désormais une meilleure expérience
    En revanche, la bibliothèque standard de Deno — par exemple @std/collections — est très bien, et je l’utilise
    Bun avait un périmètre si large qu’il envoyait beaucoup de signaux d’alerte dès le départ, mais j’étais prudemment optimiste en me disant que Jarred essayait peut-être de construire le runtime JS généraliste ultime, même si cela devait prendre des années
    Mais depuis le rachat par Anthropic, en voyant Jarred faire désormais pas mal de ~~vibe coding~~ développement agentique, et maintenant cette histoire de vibe porting, je suis convaincu que, même si ce n’est qu’une branche expérimentale, ce n’est pas un projet que j’utiliserais
    Donc Node.js continue de dominer
    Plus sérieusement, le support intégré de TypeScript et SQLite est impressionnant
    Je ne suis pas totalement anti-IA : je trouve amusant et utile de faire du vibe coding pour de petits scripts Python ou des webapps destinés à résoudre un problème très précis
    En revanche, sur des projets complexes avec beaucoup de pièces mobiles et des utilisateurs, je suis de plus en plus convaincu que le “développement agentique” à grande échelle, même s’il peut temporairement accélérer l’ajout de fonctionnalités, est au final une perte nette qui rend les projets instables et boursouflés
    Je pense à des exemples comme VSCode, Cursor, mise ou l’interface web de Perplexity
    Est-ce vraiment si difficile de faire un simple menu déroulant JS qui ne saccade pas quand on scrolle ?
    J’aimerais que davantage de gros outils, bibliothèques et projets dont je dépends s’en rendent compte et adoptent des politiques anti-IA plus strictes

  • C’est littéralement la mauvaise direction
    Je n’ai jamais vu un seul mainteneur Rust qui entretient un projet Rust de taille moyenne, disons plusieurs centaines de milliers de lignes, se dire satisfait de sa scalabilité sur une grosse codebase

    • Ravi de vous rencontrer
      Je trouve au contraire que Rust est particulièrement excellent pour les grosses codebases :
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      En revanche, pour le manier efficacement, il faut tout de même savoir un minimum ce qu’on fait :
      https://matklad.github.io/2021/09/05/Rust100k.html
      Dans ce contexte, je ne sais pas très bien comment Zig se compare à Rust
      TigerBeetle a une approche de conception assez particulière
    • Pour donner le contexte, j’ai maintenu environ six codebases Rust entre 10k et 100k lignes, mais aucune au-delà de 100k
      Je connais aussi quelques cas où un programme Rust de 20k lignes implémente les fonctionnalités principales d’un programme Go de 300k lignes
      Donc ça ne correspond pas exactement aux conditions énoncées
      Mais sur la plage 10k à 100k lignes, en tant que mainteneur, je suis très satisfait de Rust
      C’est une taille où un programme reste assez petit pour conserver une bonne cohésion, tout en étant suffisamment grand pour implémenter sérieusement une idée centrale
      À cette échelle, le langage lui-même et les outils ont été de vrais atouts, du moins dans mon expérience personnelle
    • cargo-nextest représente actuellement 84k lignes de code Rust, hors commentaires et lignes vides, et en tant que seul mainteneur, je ne pense pas qu’il me serait possible de l’écrire dans un autre langage tout en respectant mes propres critères de qualité

  • C’est peut-être à cause de ça : https://github.com/oven-sh/bun/issues/28001

    • J’aimerais qu’on explique exactement comment Rust aurait empêché ça
      Ce n’est pas un problème de sûreté mémoire temporelle