La prise en charge de Bun est désormais limitée et en voie de suppression

• Cette issue est encore Open, et à partir de la prochaine version de yt-dlp et/ou de ejs, la prise en charge de Bun sera limitée aux versions 1.2.11 à 1.3.14, tout en passant officiellement en voie de suppression
• yt-dlp continuera d’utiliser Bun comme runtime JavaScript compatible avec ejs, mais se réserve le droit de supprimer complètement la prise en charge de Bun si la charge de maintenance devient trop importante
• La version minimale prise en charge passe de 1.0.31 à 1.2.11, car construire le paquet ejs avec une version de Bun antérieure à 1.2.0 ignore le fichier de verrouillage de ejs, ce qui est considéré comme un sérieux risque de sécurité compte tenu des récentes attaques sur la supply chain npm
• La raison pour laquelle la borne inférieure est fixée à 1.2.11 et non à 1.2.0 est qu’il est impossible d’exécuter la suite de tests ejs sur les versions de Bun antérieures à 1.2.11
• La borne supérieure est fixée à 1.3.14, cette version étant présentée comme la dernière release construite sur la base de code Zig d’origine
• Le fait que Bun ait récemment été réécrit en Rust avec l’aide de Claude, et que sa direction de développement semble aller vers du « vibe-coded » intégral, est présenté comme une source future de charge de maintenance et de problèmes de confiance
• Un commentaire a rétorqué que Deno aussi serait « vibe coded », mais un mainteneur a répondu qu’il y a une grande différence entre utiliser Claude et dépendre entièrement de Claude
• À la question de savoir si les versions de 1.3.4 à 1.3.14 devraient elles aussi être exclues du support, car elles auraient pu être affectées par le « vibe coding » après le rachat par Anthropic, le mainteneur a répondu qu’il allait examiner la question
• Certains utilisateurs s’opposent à l’idée d’empêcher l’exécution des versions récentes de Bun avant même qu’un problème réel ne survienne, estimant qu’il s’agit d’une restriction préventive sans fondement, et qu’il vaudrait mieux afficher un avertissement ou ajouter un flag permettant de continuer malgré tout
• Un autre commentaire explique qu’il est possible de passer directement le chemin du binaire Bun à --js-runtimes, ce qui permet d’utiliser la dernière version de Bun au quotidien tout en pointant vers une version statique de Bun 1.3.14 uniquement pour yt-dlp
• Sont également liés une annonce sur l’arrêt du support de Node v20 et v21, ainsi qu’une issue relevant la version minimale prise en charge de Deno à v2.3.0, et il est précisé que la page wiki EJS ne reflète pas encore ce changement
• En réponse à l’afflux de commentaires venant de Hacker News, le mainteneur a laissé un commentaire épinglé demandant aux gens de se demander d’abord s’ils sont réellement concernés par l’usage de Bun avec yt-dlp avant de commenter

[GN⁺]

Commentaires sur Hacker News

• Je comprends la décision. Si l’essentiel du code n’a pas été écrit par les mainteneurs eux-mêmes, il doit être difficile de vraiment comprendre la base de code.
  En pratique, il est aussi quasiment impossible de relire une réécriture complète. Il y a précisément 1 million de lignes de code : https://github.com/oven-sh/bun/pull/30412

  • Le passage de Zig à Rust ne veut pas dire qu’on oublie soudain ce que contient un fichier, comment il fonctionne et comment il se relie aux autres.
    Au fond, c’est surtout le même contenu écrit dans une autre syntaxe, et j’ai l’impression que les développeurs Rust trouvent juste ce code peu agréable à lire. Les développeurs de Bun semblaient vouloir du code qui leur paraisse plus familier.
    Cela dit, je pense qu’ils auraient dû appeler ça 2.0. Ça aurait donné moins l’impression de se précipiter. Il y a déjà quelques régressions dans la 1.3.14, mais en ce moment il y a tellement de petits incendies liés à Rust que personne ne semble trop s’en soucier.
    Le vrai problème plus large, c’est que Bun continue de courir après des nouvelles fonctionnalités brillantes sans jamais vraiment les terminer. Les tests couvrent l’essentiel de Vitest, mais pas tout, l’essentiel de Jest, mais pas tout, et l’essentiel de pnpm, mais pas tout. Maintenant il y a aussi une fonctionnalité d’images, donc l’essentiel de sharp, mais pas tout. Le serveur de développement couvre l’essentiel de Vite, mais là encore pas tout. Les processus longue durée sont globalement comparables à Node, mais avec des fuites mémoire, et c’est probablement ce qui a motivé le passage à Rust.
    Quand j’ai vu le billet sur les routines d’image, ça m’a un peu refroidi. C’était encore un nouvel objet brillant, et avec les bugs de test en plus, j’ai fini par migrer complètement vers Vitest
  • Dire qu’on a pu écrire environ 2 millions de lignes de Zig, avec en plus la possibilité de continuer à utiliser la même suite de tests incluse dedans, mais qu’on ne peut pas relire 1 million de lignes de Rust, ce n’est pas très convaincant.
    Je ne suis pas sûr que cette réécriture soit une bonne idée ni qu’elle réussira, mais l’argument inverse n’est pas non plus très convaincant
  • C’est assez courant dans les cultures d’entreprise où le turnover est élevé. On t’assigne à une équipe censée “maintenir” une base de code vieille de 10 ans, longue de plusieurs millions de lignes, et même la personne la plus ancienne de l’équipe n’est là que depuis 1 ou 2 ans.
    Personne ne sait vraiment ce que font ces plus d’un million de lignes. Personne n’y met de passion. On reçoit des demandes, et tout ce qui n’est pas directement à toucher est traité comme une boîte noire.
    C’est comme ça qu’on se retrouve avec 14 implémentations de services en arrière-plan qui font la même chose, 8 dépendances jouant le même rôle, 6 frameworks qui se chevauchent, et une incohérence totale de style et d’approche. Et pourtant, ça ne semble pas trop préoccuper les gens
  • Dans certaines grosses bases de code dont je m’occupe en ce moment, il y en a qui ont été générées avec des outils de type agent, et la personne qui les a produites ne comprend presque pas comment elles fonctionnent.
    C’est sans doute mieux que du pur « vibe coding », mais si ça peut passer pour des parties peu critiques, j’ai du mal à l’accepter pour une infrastructure centrale qui demande une vraie réflexion en profondeur
  • Ils supportent aussi Windows, et sous Windows il y a actuellement déjà plusieurs millions de lignes de code qui n’ont pas été écrites par les mainteneurs actuels

• Ce n’est pas comme discriminer quelqu’un selon sa race ou sa religion. Si on ne veut pas d’une grande surface de code vibe codée, faut-il vraiment se justifier ?
  Cela relève de la marge de manœuvre “artistique” du développeur, et on semble avoir oublié que le logiciel comporte intrinsèquement une part d’opinion

  • À lire certains messages dans l’issue GitHub, on dirait que certaines personnes ont l’impression qu’on a offensé leur religion
  • En lisant les commentaires, on a l’impression que beaucoup de gens supposent que le titre parle de Bun lui-même
  • Oui. Le forker et ne changer que le numéro de version minimale ne devrait pas être bien difficile. Je n’ai pas vérifié, mais il est probable qu’il suffise de modifier un chiffre quelque part.
    Si ça fonctionne, ça continuera de fonctionner. C’est juste qu’ils ne veulent pas le supporter ni le maintenir, ni corriger les problèmes associés
  • On pourrait aussi dire que c’est comparable à une discrimination raciale ou religieuse, dans le sens où cela exclut sur la base d’un critère arbitraire et sans signification.
    Si Bun porté en Rust est meilleur sur tous les plans mesurables, passe tous les tests, offre des performances équivalentes ou supérieures et corrige des bugs existants, alors pourquoi l’importance du langage utilisé ou de la manière dont c’est implémenté ? L’essentiel, c’est que la qualité est supérieure.
    Si vous ne faites pas confiance à l’équipe Bun quand elle publie et valide une version Rust, il n’est pas non plus logique de dire que vous faisiez confiance à la version Zig d’il y a deux semaines. Les développeurs de yt-dlp donnent alors l’air stupide

• J’aime vraiment beaucoup utiliser Bun, donc voir la direction changer comme ça après l’acquisition par Anthropic me rend un peu triste.
  Je veux un bon Node « batteries incluses », mais pas qu’il soit vibe codé

  • Je me demande si la conversion vibe codée a réellement déjà causé de gros problèmes.
    Je ne dis pas que je soutiens la fusion. Je suis opposé à ce genre d’approche d’ingénierie en mode YOLO. Mais je n’ai pas suivi les nouvelles depuis l’annonce, donc je me demande comment la transition se passe
  • D’après l’équipe Bun, ils faisaient déjà du vibe coding depuis plusieurs mois avant l’acquisition par Anthropic
  • Au moment de l’acquisition, les gens s’attendaient à ce que Bun continue plus ou moins comme avant, et c’est assez ironique de voir que cette attente a finalement été totalement renversée et détruite.
    Enfin, ironique au sens tragiquement triste du terme
  • S’il n’y a pas eu de problème concret confirmé à cause du « vibe coding », j’ai l’impression qu’un rejet automatique sans vérifier les éléments réels ressemble lui-même un peu au comportement qu’il prétend critiquer

• Cette décision ressemble plus à un jugement politique qu’à un jugement d’ingénierie. Avez-vous déjà vu davantage de segfaults, d’erreurs de mémoire, de vulnérabilités de sécurité ou de bugs dans Bun depuis la réécriture Rust ?
  Bien sûr que non, puisque cette réécriture n’a même pas encore été intégrée. On a l’impression que la décision repose surtout sur un malaise vis-à-vis de l’intervention de l’IA.
  On choisit des outils d’ingénierie non pas selon son ressenti, mais selon leur capacité à faire ce qu’on veut. Si Bun accumule plus de bugs et devient un moins bon logiciel, je ne l’utiliserai pas, mais ce jugement sera fondé sur des données. Jarred a déjà accompli des choses impressionnantes avec Bun, et il semble peu probable qu’il publie une réécriture qui ne respecte pas ses propres critères de qualité, donc je vais observer

  • À l’inverse, yt-dlp n’a aucune obligation de servir de cobaye pour vérifier si le nouveau processus de développement de Bun augmente les segfaults, les erreurs mémoire ou les vulnérabilités de sécurité.
    Si on pense raisonnablement qu’il y a un risque accru de vulnérabilités de sécurité, expérimenter sur les utilisateurs serait plutôt de la négligence.
    Le choix responsable ressemble davantage à : « nous ne prendrons pas immédiatement en charge l’exécution de notre logiciel sur la nouvelle release de Bun coupée depuis le main actuel ».
    En revanche, il est dommage que cela semble indiquer non pas un plan de réévaluation des versions futures, mais l’intention de ne plus jamais le supporter. Bien sûr, les développeurs de yt-dlp ne doivent rien à personne
  • Ce n’est pas forcément politique. yt-dlp peut agir politiquement, mais le principe consistant à ne pas adopter une dépendance critique en production avant qu’elle n’ait été largement utilisée pendant 6 mois à 1 an n’a généralement rien de politique.
    Une réécriture complète de 1 million de lignes, c’est en pratique un nouveau runtime avec le même ABI qu’avant, et pour beaucoup de consommateurs en aval, c’est une dépendance de production difficile à accepter.
    Même si, pour les besoins du débat, on supposait que Bun avait été entièrement réécrit à la main par des humains, ce serait pareil. Je trouve ce genre de décision assez standard, et personnellement je pense aussi que la qualité de la réécriture LLM de Bun sera globalement bonne, mais je n’y engagerais ni mon produit ni mon entreprise. Si un changement est risqué, je veux choisir moi-même de l’assumer dans mon logiciel, pas me le faire imposer par une dépendance indirecte
  • Si on attend qu’il y ait plus de segfaults, de problèmes mémoire ou d’autres ennuis, c’est qu’on a déjà échoué à éviter le problème. Je pense que c’est la bonne direction, et l’histoire montrera qui avait raison
  • Dans un projet, la gouvernance est extrêmement importante. Le fait que les auteurs de Bun se soient inclinés devant le nouveau propriétaire montre clairement où sont les priorités.
    Je ne vais pas rester assis à attendre que les bugs explosent et que tout parte en vrille.
    Si un projet est tenu par des gens qui choisissent leurs outils uniquement selon leur capacité à “faire ce qu’ils veulent”, je le retirerai de mes dépendances
  • L’un des éléments essentiels de l’ingénierie consiste à prévoir la trajectoire actuelle. En ce sens, éviter des outils qui inspirent un mauvais pressentiment est parfaitement légitime.
    Le moment le plus simple pour échapper à un outil voué à devenir un accident ferroviaire, c’est avant même de l’intégrer

• Cela concerne la conversion Rust de Bun, mais elle n’est pas encore sortie.
  Ils parlent de « problèmes prévisibles de compatibilité et de sécurité », mais la version Zig de Bun plante déjà pas mal elle aussi.
  J’aimerais que yt-dlp donne un lien vers des éléments détaillant pourquoi il y aurait des problèmes de compatibilité prévisibles. Les deux projets ont des suites de tests, donc dans un monde idéal une réécriture rapide devrait être possible.
  C’est peut-être simplement pour éviter d’envenimer la situation, mais s’ils ont identifié des problèmes concrets, j’aimerais les voir.
  Bun.rs aurait dû être non pas une release mineure, mais une 1.4 ou 2.0, et j’aurais aussi aimé qu’il y ait des releases alpha/bêta

  • Si un projet avait réellement signalé de graves régressions sous Bun.rs avec des données à l’appui, ce serait différent.
    Mais cela ne fait qu’une semaine que c’est public, et jusqu’ici on ne voit quasiment aucune donnée réelle sur des régressions. Cela ressemble davantage à des plaintes du type « je n’aime juste pas ça »

• Cette logique se lit à peu près comme : « libfoo a commencé à être développé avec emacs au lieu de vim, donc on ne peut plus lui faire confiance ».
  Bien sûr, ce n’est pas exactement la même chose, mais il y a une raison pour laquelle cela donne cette impression.
  En logiciel, la seule vérité qui compte, c’est est-ce que ça marche pour mon cas d’usage. Même avant l’IA, on ne savait pas forcément si l’auteur travaillait de manière rigoureuse ou s’il tâtonnait jusqu’à ce que ça passe.
  Autrement dit, je n’ai jamais évalué un logiciel en enquêtant sur sa méthodologie ou sur les outils employés. J’ai utilisé énormément de logiciels sans suite de tests ou avec des suites médiocres, et les gens qui aiment la sécurité mémoire utilisent aussi des outils écrits en C, et inversement.
  Donc la logique du type « je ne l’utiliserai pas parce que je n’aime pas la manière dont l’IA a été utilisée » me semble à peine plus convaincante que d’arrêter d’utiliser un logiciel parce qu’on n’aime pas le choix d’éditeur de son auteur

  • Il existe pourtant clairement des gens qui se soucient de la manière dont les choses sont produites et qui prennent leurs décisions en fonction de leur accord ou non avec ce processus.
    Sinon, des concepts comme le chocolat/café équitable n’existeraient pas
  • Cette analogie va trop loin. Il faut la lire comme si l’on n’était même pas dans le même stade, ni dans des stades voisins
  • Alors allons un cran plus loin : imaginons un cron job qui, chaque premier lundi du mois, réécrit toute la base de code dans un nouveau langage. De Rust à C++, puis Go, puis Swift, puis retour au point de départ.
    Pour les clients qui utilisent le produit, est-ce que ce serait vraiment presque la même chose que si le mainteneur changeait d’éditeur, donc un détail sans importance ?
  • La plupart des gens considèrent que l’éditeur de texte utilisé n’a pas d’influence significative sur le code produit.
    Mais il y a bien moins de gens qui diraient la même chose à propos des LLM.
    Peut-être que le Bun vibe codé sera aussi bon voire meilleur que l’ancien Bun, mais comment le savoir aujourd’hui ?
    Et l’affirmation selon laquelle « on ne savait pas si le logiciel était rigoureux, donc on ne le jugeait pas sur sa méthodologie » n’est pas vraie non plus. Certaines personnes vérifient directement si un projet respecte un niveau de rigueur acceptable avant de l’adopter ou de décider de continuer à l’utiliser. Moi, je le fais pour les éléments importants.
    Beaucoup plus de gens utilisent des signaux de réputation : ce n’est pas parfait, mais il y a une corrélation, cela peut suffire, et c’est bien plus simple qu’une revue manuelle complète

• Il nous faut urgemment un nouveau terme pour décrire la manière d’utiliser les LLM dans le travail de développement. « Vibe coding » a une définition stricte, mais personne ne semble vraiment s’en soucier.
  Il est vraiment difficile de croire que ce portage Rust ait été réalisé à 100 % en pur « vibe » au sens de la définition d’origine.
  Le débat est devenu un marécage émotionnel dans les deux sens, et utiliser « vibe coding » comme une simple insulte générique contre l’usage des LLM rend très difficile l’identification du problème réel dont on parle.
  J’utilise les LLM pour m’assister dans le développement, et je fais un meilleur travail plus vite selon tous les critères qu’un ingénieur jugerait importants

  • À l’origine, le vibe coding voulait dire « se laisser porter par l’ambiance [...] jusqu’à oublier que le code existe même ».
    https://x.com/karpathy/status/1886192184808149383
    Dans le cas précis de ce portage, ça a avancé si vite qu’il semble clair qu’aucun humain n’a validé la justesse de la traduction. On ne sait même pas encore clairement si une validation manuelle aura réellement lieu ensuite.
    Cela dit, si on prend le critère de Dijkstra, la plupart des projets logiciels faisaient déjà du “vibe coding” bien avant l’arrivée de l’IA : ils se reposaient sur l’ambiance en oubliant l’existence même de l’exactitude.
    Garantir la justesse d’un code complexe est difficile, mais cela va devenir de moins en moins optionnel maintenant qu’on vit à l’époque d’un milliard de hackers dans le datacenter.
    Ajout : « Le port Rust pré-release de Bun contient 13 365 blocs unsafe »
    https://news.ycombinator.com/item?id=48239790
  • Contrairement à l’idée qu’utiliser des LLM permet de faire un meilleur travail plus vite, des recherches suggèrent que cela peut ne pas être plus rapide, voire être plus lent.
    La technologie étant encore très récente, les études sont difficiles, mais même dans une lecture optimiste, les preuves empiriques semblent montrer seulement environ 3 % d’amélioration dans certains domaines.
    Écrire du code est rarement le goulot d’étranglement de notre travail

• Je ne comprends pas pourquoi tant de gens se sentent autant concernés par cette décision. Si vous êtes de vrais amateurs de vibe coding, pourquoi ne pas simplement vibe coder vous-mêmes un meilleur yt-dlp, ou forker l’existant pour en faire ce que vous voulez ?

  • On nous a beaucoup dit que le vibe coding avait rendu la création de logiciels ridiculement facile et que n’importe qui pouvait en produire à toute vitesse.
    Certains allaient même jusqu’à dire que les gens vibe coderaient des logiciels personnels jetables pour tout et n’importe quoi.
    Dans ce cas, les vibe coders ne devraient avoir aucune raison de se plaindre d’une décision logicielle quelle qu’elle soit. Vibe coder un fork personnel plus à leur goût devrait être un jeu d’enfant, non ? N’était-ce pas la promesse du vibe coding ?
  • En plus, yt-dlp prend déjà en charge les plugins d’interpréteurs tiers. Ils disent simplement qu’ils ne veulent pas supporter Bun eux-mêmes, et l’infrastructure permettant à d’autres d’utiliser ce qu’ils veulent existe déjà.
    C’est ce sentiment de droit mal placé que les gens éprouvent souvent face à des projets maintenus par le temps et les efforts d’autrui. Cette manière de vouloir enrôler librement le temps et le travail des autres comme bénévoles pour obtenir les fonctionnalités qu’on veut reste toujours frappante.
    Ceux qui font le travail ont le droit de prendre les décisions, et si ça ne plaît pas, il suffit de forker soi-même. Cet écosystème a toujours fonctionné ainsi.
    Et yt-dlp reste aujourd’hui encore étonnamment facile à modifier
  • Pour beaucoup de fans de l’IA, pas tous mais beaucoup, cela fonctionne presque comme une religion. Ils ne se contentent pas de laisser chacun vivre sa vie et l’histoire montrer quelle méthode de construction logicielle est la meilleure ; ils exigent que tout le monde soit d’accord avec eux.
    Je vis déjà ce genre de situation au travail, et c’est vraiment insupportable que, dès qu’il s’agit d’IA, un désaccord technique honnête ne soit plus permis

• Je ne sais pas trop quoi penser de la réécriture de Bun.
  D’un côté, le fait qu’une grande partie de la base de code n’ait pas été relue fait très peur.
  D’un autre côté, j’ai entendu dire que les tests passaient avec très peu de régressions.
  C’est peut-être parce que je manque d’expérience dans ce domaine, mais je ne pense pas faire suffisamment confiance aux tests pour m’y reposer entièrement sans lire le code