Electrobun 2.0 va se séparer de Bun en raison de sa réécriture en Rust

• Electrobun 2.0 va évoluer pour réduire sa dépendance à Bun, en raison de la réécriture de Bun en Rust, dans une logique similaire à la décision prise par yt-dlp, et sa structure de dépendances au runtime devrait également changer
• La décision de séparation a aussi été influencée par l’estimation qu’Anthropic ne faisait pas passer suffisamment de revue humaine, de déploiement raisonné et de processus de stabilisation
• Rust est lui-même évalué positivement et fera partie des langages pris en charge en priorité dans Electrobun 2.0
• En plus de Rust, Electrobun 2.0 prévoit d’inclure Zig et Go parmi ses langages pris en charge en priorité
• Le projet lié peut être consulté dans le dépôt blackboardsh/electrobun, et l’orientation centrale consiste à réduire la dépendance à Bun

[GN⁺]

Avis sur Hacker News

• Toute cette affaire est vraiment intéressante, et ressemble à plus qu’un simple spectacle : on dirait un signe avant-coureur du développement logiciel en 2026

  • Pour être précis, le terme exact est bellwether, qui vient du mouton castré portant une cloche qu’on utilisait pour guider le troupeau
  • Ce qui est encore plus drôle, c’est que personne ne veut abandonner npm, alors qu’il continue d’être détourné et piraté
    Combien de fois npm a-t-il déjà été à l’origine de piratages à l’échelle de l’industrie ? Il y a eu au moins trois gros incidents, sans compter des campagnes massives d’attaques de la chaîne d’approvisionnement visant npm. Et malgré ça, le vrai sujet d’inquiétude serait bun
    Il est temps de regarder la réalité en face, de réexaminer npm et de l’évaluer sérieusement. La situation échappe au contrôle de façon dangereuse
  • On verra bien avec le temps. À mon avis, ce sera encore le même schéma qui se répète depuis 20 ans : les gens sur Internet s’énervent contre $latest_thing, puis passent vite à un autre sujet brûlant
  • La métaphore la plus juste me semble être moins une girouette qu’un canari dans la mine
  • Je me demande, au départ, combien d’entreprises « en retard et pas vraiment modernes » utilisaient réellement Bun ou Deno
    D’un autre côté, ça ressemble aussi à une faible surréaction. Après tout, on n’audite pas ligne par ligne le kernel, les pilotes, le BIOS ou le code EFI avant d’exécuter Linux, n’est-ce pas ? Si les tests passent, que les performances ne régressent pas et que c’est sûr, je ne comprends pas pourquoi le fait que ce soit du vibe coding met autant les gens en colère. Est-ce parce que c’est irresponsable ? Je comprends les deux points de vue

• Dépôt Electrobun : https://github.com/blackboardsh/electrobun
  Electrobun vise à être une solution complète pour créer, mettre à jour et déployer des applications desktop ultra-rapides, légères et cross-platform écrites en TypeScript. En interne, il utilise bun pour exécuter le processus principal et bundler le TypeScript de la webview, avec des bindings natifs écrits en Objc et C++, ainsi que des parties centrales écrites en Zig

• Il semble raisonnable d’éviter les grosses codebases produites avec des LLM tant qu’il n’est pas démontré qu’elles peuvent être maintenues soit par des LLM, soit par un effort humain raisonnable

  • Ce qui m’étonne, c’est que les gens concluent tout de suite que Bun est un « déchet IA »
    Bun était déjà développé presque entièrement avec des LLM pendant environ six mois, bien avant la réécriture en Rust. Source : https://x.com/jarredsumner/status/2054525268296118363
    On peut donc considérer qu’il est déjà démontré que des LLM peuvent maintenir ce type de codebase
  • Il existe un moyen de voir si une codebase se dégrade sous maintenance par agent IA
    Il suffit de collecter et d’analyser la manière dont l’agent de code lit le code pendant le développement, puis de vérifier si, pour des tâches similaires, la quantité de code consultée et la consommation de tokens augmentent régulièrement. Si, du point de vue de l’agent, la lisibilité du code ne se détériore pas, alors la maintenabilité de la codebase devrait rester correcte

• Je reste clairement sceptique face aux logiciels écrits ou réécrits entièrement par des LLM, mais concernant les vecteurs de cyberattaque, il faut sans doute supposer qu’Anthropic a suffisamment testé cela avec son nouveau modèle Mythos
  Peut-être ont-ils d’ailleurs communiqué des informations plus détaillées à ce sujet

  • Comment peut-on savoir ce que signifie « suffisamment testé » sur un million de lignes de code ?
    À moins qu’une ligne de code ne corresponde à un token, on ne peut pas faire tenir un million de lignes de code dans une fenêtre de contexte d’un million de tokens. Au final, on ne fait que brûler assez de temps et d’argent en tokens en espérant que les mauvaises parties ou les erreurs finissent par apparaître
  • Il ne serait pas surprenant que les problèmes de sécurité que les LLM produisent facilement soient justement le type de failles de sécurité qu’ils détectent difficilement
  • Donc on défend du code généré par LLM avec un autre LLM, et ce sont encore d’autres LLM qui attaquent ? Quel que soit le résultat et ses conséquences pour nous, c’est eux qui gagnent à la fin ?
  • Jarred a dit que cette affaire n’avait rien à voir avec Mythos ni Anthropic

• Je n’avais jamais entendu parler d’Electrobun, mais ça a l’air de pouvoir être une bonne alternative à Electron. Leur site mentionne le bundling de CEF comme option ; je me demande si quelqu’un l’a essayé

• J’ai découvert Electrobun aujourd’hui. Par rapport à Electron, ça donne quoi ?

  • La différence, c’est +bu

• Le nom devrait probablement être changé

• À ce stade, je me demande si quelqu’un va fork Bun basé sur Zig pour faire autre chose

• C’est assez logique
  Par exemple, beaucoup d’organisations, dont la nôtre, dépendent fortement de numpy. numpy existe depuis des décennies et a largement fait ses preuves en production. Si quelqu’un réécrivait en vibe coding une nouvelle version de numpy en une semaine en garantissant que « tous les tests passent », est-ce qu’on l’adopterait ? Absolument pas. On n’aurait aucune certitude sur l’absence de bugs potentiels, ni aucune confiance totale dans les résultats
  Le point clé, ce n’est pas qu’il ait été réécrit par une IA, mais qu’il ait fait ses preuves dans le temps et en conditions réelles. Même si une équipe humaine le réécrivait en une semaine, on ne lui ferait pas confiance et on ne l’utiliserait pas

  • Le « ça a été fait en une semaine » revient souvent sur HN, mais cette PR n’était pas une release. La réécriture en Rust est en cours depuis plus d’un mois et n’a pas encore été déployée
  • C’est un peu comme dire : « Il m’a fallu un mois pour fabriquer ce placard à la main, mais si quelqu’un le faisait à la machine en une journée, est-ce que je lui ferais confiance ? »

• Le nom est assez proche du tristement célèbre Electron ; est-ce que c’est similaire ?