Die Unterstützung für Bun wird nun eingeschränkt und als veraltet markiert

• Dieses Issue ist noch Open; ab dem nächsten Release von yt-dlp und/oder ejs wird der Unterstützungsumfang für Bun auf 1.2.11 bis einschließlich 1.3.14 begrenzt, und die Unterstützung selbst wird als veraltet eingestuft
• yt-dlp wird Bun weiterhin als mit ejs kompatible JavaScript-Laufzeit verwenden, behält sich aber das Recht vor, die Bun-Unterstützung vollständig zu entfernen, falls der Wartungsaufwand zu groß wird
• Die minimal unterstützte Version wird von bisher 1.0.31 auf 1.2.11 angehoben; beim Builden des ejs-Pakets mit Bun vor 1.2.0 wird die ejs-Lockdatei ignoriert, was angesichts der jüngsten npm-Supply-Chain-Angriffe als erhebliches Sicherheitsrisiko angesehen wird
• Der Grund, warum nicht 1.2.0, sondern 1.2.11 als Untergrenze festgelegt wurde, ist, dass sich mit Bun vor 1.2.11 die ejs-Testsuite nicht ausführen lässt
• Die Obergrenze wurde auf 1.3.14 festgelegt; als Begründung wird angeführt, dass dies das letzte Release war, das noch auf der ursprünglichen Zig-Codebasis gebaut wurde
• Dass Bun kürzlich mit Claude in Rust neu geschrieben wurde und die Entwicklungsrichtung auf ein „vollständig vibe-coded“ hindeute, wird als künftige Belastung für Wartbarkeit und Vertrauen genannt
• Ein Kommentar entgegnete, dass auch Deno „vibe coded“ werde, worauf der Maintainer antwortete, dass es einen großen Unterschied zwischen der Nutzung von Claude und der vollständigen Abhängigkeit von Claude gebe
• Auf die Frage, ob dann nicht auch 1.3.4 bis 1.3.14 wegen möglicher Einflüsse von „vibe coding“ nach der Anthropic-Übernahme von der Unterstützung ausgeschlossen werden müssten, antwortete der Maintainer, dass dies geprüft werde
• Einige Nutzer widersprachen und meinten, das Blockieren neuer Bun-Versionen noch vor dem Auftreten realer Probleme sei eine unbegründete präventive Einschränkung; stattdessen solle es Warnungen oder Flags geben, damit die Ausführung weiter möglich bleibe
• Ein anderer Kommentar erklärte, dass sich über --js-runtimes der Pfad zu einer Bun-Binärdatei direkt übergeben lasse; dadurch könne man die neueste Bun-Version wie gewohnt weiterverwenden und nur für yt-dlp statisch Bun 1.3.14 angeben
• Als verwandte Hinweise wurden außerdem ein Issue zum Ende der Unterstützung für Node v20·v21 und ein Issue zur Anhebung der minimal unterstützten Deno-Version auf v2.3.0 verlinkt; zudem wird darauf hingewiesen, dass das EJS-Wiki-Dokument diese Änderung noch nicht widerspiegelt
• Der Maintainer hinterließ mit Blick auf Kommentare von Hacker News einen angehefteten Kommentar mit der Bitte, vor dem Posten erst zu überlegen, ob tatsächlich ein Interesse an Problemen mit Bun in yt-dlp besteht

[GN⁺]

Hacker-News-Kommentare

• Die Entscheidung ist nachvollziehbar. Wenn der Großteil des Codes nicht vom Maintainer selbst geschrieben wurde, ist es vermutlich schwer, die Codebasis wirklich zu verstehen.
  Selbst den komplett neu geschriebenen Code zu prüfen, ist praktisch unmöglich. Es sind immerhin genau 1 Million Zeilen Code https://github.com/oven-sh/bun/pull/30412

  • Ich glaube nicht, dass man durch den Wechsel von Zig zu Rust plötzlich nicht mehr weiß, was eine bestimmte Datei enthält, wie sie funktioniert und wie sie mit anderen Dateien zusammenhängt.
    Im Grunde ist es fast derselbe Inhalt in einer anderen Syntax, und deshalb sieht es für Rust-Entwickler wohl unschön aus. Die Bun-Entwickler wollten anscheinend Code, der ihnen vertrauter vorkommt.
    Allerdings hätte man das meiner Meinung nach 2.0 nennen sollen. Dann hätte es sich auch weniger überstürzt angefühlt. Selbst in 1.3.14 gibt es schon ein paar Regressionen, aber gerade scheint es so viele kleine Rust-bezogene Brände zu geben, dass sich kaum jemand groß daran stört.
    Das größere Problem ist, dass Bun ständig glänzenden neuen Features hinterherjagt und sie nicht zu Ende bringt. Tests sind größtenteils, aber nicht vollständig, Vitest; größtenteils, aber nicht vollständig, Jest; und pnpm größtenteils, aber eben auch nicht vollständig. Jetzt gibt es auch Bildfunktionen, also größtenteils sharp, aber ebenfalls nicht vollständig. Der Dev-Server ist größtenteils Vite, aber wieder nicht komplett. Lang laufende Prozesse sind größtenteils wie bei Node, haben aber Memory Leaks, und das dürfte wohl die Motivation für den Rust-Wechsel gewesen sein.
    Als ich den Beitrag über die Bildroutinen gesehen habe, ist mir etwas das Herz gesunken. Wieder ein neues glänzendes Objekt, und zusammen mit den Test-Bugs bin ich am Ende komplett zu Vitest gewechselt
  • Zu sagen, dass man ungefähr 2 Millionen Zeilen Zig-Code schreiben konnte und denselben darin enthaltenen Test-Suite weiterverwenden kann, aber 1 Million Zeilen Rust-Code nicht prüfen könne, ist nicht besonders überzeugend.
    Ich bin nicht sicher, ob dieses Rewrite selbst eine gute Idee ist und gut ausgehen wird, aber die Gegenargumentation überzeugt mich genauso wenig
  • Das ist in Unternehmenskulturen mit hoher Fluktuation ziemlich häufig. Man wird einem „gewarteten“ Team für eine zehn Jahre alte Codebasis mit mehreren Millionen Zeilen zugeteilt, und selbst die Person mit der längsten Betriebszugehörigkeit ist vielleicht erst seit 1–2 Jahren da.
    Niemand weiß, was diese über 1 Million Zeilen eigentlich tun. Niemand geht mit Begeisterung daran. Man bekommt Anforderungen, und abgesehen von der Oberfläche, die man anfassen muss, behandelt man alles andere als Blackbox.
    So entstehen 14 Implementierungen desselben Background-Service, 8 Abhängigkeiten mit derselben Aufgabe, 6 sich überschneidende Frameworks und ein völliges Durcheinander aus Stil und Herangehensweise. Und trotzdem gilt das kaum als wichtig
  • Bei manchen ziemlich großen Codebasen, mit denen ich gerade arbeite, wurden Teile mit agentischen Tools erzeugt, deren Funktionsweise die Person, die sie erstellt hat, kaum versteht.
    Ich halte das für besser als reines „Vibe Coding“, aber bei unwichtigen Teilen mag das noch in Ordnung sein — bei wirklich durchdachter Kerninfrastruktur ist es schwer akzeptabel
  • Sie unterstützen auch Windows, und unter Windows gibt es derzeit Millionen Zeilen Code, die ebenfalls nicht vom aktuellen Maintainer geschrieben wurden

• Es ist ja nicht so, als würde man jemanden wegen Ethnie oder Religion diskriminieren. Wenn man keinen großflächigen vibe-gecodeten Oberflächenbereich will, muss man sich dafür doch nicht rechtfertigen.
  Das fällt unter den „künstlerischen“ Ermessensspielraum von Entwicklern, und man scheint vergessen zu haben, dass Software von Natur aus Meinungen enthält

  • Wenn man einige Beiträge im GitHub-Issue liest, scheinen manche sich in ihrer Religion angegriffen zu fühlen
  • In den Kommentaren scheinen viele anzunehmen, der Titel beziehe sich auf Bun selbst
  • Genau. Es dürfte nicht schwer sein, einen Fork zu erstellen und einfach nur die minimale Versionsnummer hochzusetzen. Ich habe es nicht nachgesehen, aber vermutlich müsste man irgendwo nur eine Zahl ändern.
    Wenn es funktioniert, wird es weiter funktionieren. Sie wollen es nur nicht unterstützen und warten und dafür Issues lösen
  • Man könnte es durchaus mit Diskriminierung wegen Ethnie oder Religion vergleichen — insofern, als hier nach willkürlichen und bedeutungslosen Kriterien ausgeschlossen wird.
    Wenn das auf Rust portierte Bun in jeder messbaren Hinsicht besser wäre, alle Tests bestünde, gleich gut oder besser performte und bestehende Bugs behöbe, warum sollte dann wichtig sein, in welcher Sprache es geschrieben wurde und wie es implementiert wurde? Entscheidend wäre doch, dass die Qualität höher ist.
    Wenn man dem Bun-Team nicht traut, nachdem es die Rust-Version veröffentlicht und abgesegnet hat, ist es logisch auch fragwürdig, warum man der Zig-Version vor zwei Wochen getraut hat. Die yt-dlp-Entwickler wirken dadurch töricht

• Ich benutze Bun wirklich sehr gern, deshalb macht es mich etwas traurig, dass sich die Richtung seit der Anthropic-Übernahme so verändert hat.
  Ich möchte ein gutes Node mit Batteries Included, aber ich möchte nicht, dass es vibe-gecodet ist

  • Ich frage mich, ob die vibe-gecodete Umstellung tatsächlich schon größere Probleme verursacht hat.
    Das heißt nicht, dass ich den Merge unterstütze. Ich bin gegen solche YOLO-artigen Engineering-Ansätze. Ich habe seit der Ankündigung nur nichts mehr verfolgt und frage mich, wie die Umstellung läuft
  • Laut dem Bun-Team wurde schon seit einigen Monaten vor der Anthropic-Übernahme vibe-gecodet
  • Zum Zeitpunkt der Übernahme hatten die Leute noch erwartet, dass Bun im Großen und Ganzen wie bisher weiterlaufen würde, und dass diese Erwartung dann völlig auf den Kopf gestellt und zerstört wurde, ist schon irgendwie komisch.
    Natürlich im furchtbar traurigen Sinn von komisch
  • Wenn keine konkreten Probleme nachgewiesen wurden, die durch „Vibe Coding“ entstanden sind, ist die reflexhafte Ablehnung ohne Prüfung der tatsächlichen Grundlage dann nicht selbst einer ähnlichen Reaktion sehr nahe wie das, was kritisiert wird?

• Diese Entscheidung wirkt eher wie eine politische Bewertung als eine technische. Habt ihr seit dem Rust-Rewrite bei Bun mehr Segmentation Faults, Out-of-Memory-Fehler, Sicherheitslücken oder Bugs gesehen?
  Natürlich nicht, denn das Rewrite ist ja noch gar nicht integriert. Es wirkt so, als würde hier nach Bauchgefühl gegen AI-Beteiligung entschieden.
  Engineering-Tools wählt man nicht nach Gefühl aus, sondern danach, ob sie tun, was man will. Wenn Bun mehr Bugs bekommt und sich wie schlechtere Software anfühlt, würde ich es nicht nutzen, aber diese Einschätzung würde auf Daten basieren. Jarred hat mit Bun schon viele beeindruckende Dinge gemacht, und es erscheint unwahrscheinlich, dass er ein Rewrite veröffentlicht, das seinen Qualitätsmaßstäben nicht genügt — ich würde also erst einmal abwarten

  • Umgekehrt ist yt-dlp nicht verpflichtet, für Bun zu experimentieren, ob dessen neuer Entwicklungsprozess zu mehr Segmentation Faults, Out-of-Memory-Fehlern oder Sicherheitslücken führt.
    Wenn man vernünftigerweise von einem erhöhten Risiko für Sicherheitsprobleme ausgeht, wäre es eher fahrlässig, an den Nutzern zu experimentieren.
    Die verantwortungsvolle Entscheidung ist eher: „Wir unterstützen die Ausführung unserer Software auf dieser neuen Bun-Version, die gerade vom main abgeschnitten wurde, vorerst nicht sofort.“
    Schade ist nur, dass es nicht wie ein Plan wirkt, spätere Releases neu zu bewerten, sondern eher wie die Absicht, es niemals wieder zu unterstützen. Natürlich schulden die yt-dlp-Entwickler niemandem etwas
  • Es muss nicht unbedingt politisch sein. yt-dlp mag politisch handeln, aber der Grundsatz, eine Kernabhängigkeit erst dann in Produktion zu übernehmen, wenn sie 6–12 Monate breit eingesetzt wurde, ist normalerweise nicht politisch.
    Ein vollständiges Rewrite von 1 Million Zeilen ist faktisch eine neue Runtime mit demselben ABI wie zuvor, und für viele Downstream-Nutzer ist das als Produktionsabhängigkeit unangenehm.
    Selbst wenn wir für die Diskussion annehmen, dass Bun komplett von Hand neu geschrieben worden wäre, wäre die Lage dieselbe. Ich halte solche Entscheidungen für ziemlich standardmäßig, und obwohl ich persönlich glaube, dass die Qualität des LLM-Rewrites insgesamt wohl gut sein wird, würde ich weder mein Produkt noch mein Unternehmen darauf verwetten. Riskante Änderungen möchte ich in meiner Software selbst auswählen und nicht wegen einer transitive Abhängigkeit aufgezwungen bekommen
  • Wenn man wartet, bis Segmentation Faults, Out-of-Memory-Fehler und andere Probleme tatsächlich zunehmen, hat man bereits versagt, das Problem zu vermeiden. Ich halte diese Richtung für richtig, und die Geschichte wird zeigen, wer recht hatte
  • In Projekten ist Governance enorm wichtig. Dass die Bun-Autoren vor dem neuen Eigentümer eingeknickt sind, zeigt, wo die Prioritäten liegen.
    Ich werde nicht untätig zusehen, bis Bugs explodieren und alles auseinanderfällt.
    Wenn ein Projekt von Menschen betrieben wird, die nur darauf schauen, ob „das Tool tut, was ich will“, würde ich es aus meinen Abhängigkeiten entfernen
  • Einer der Kernelemente von Engineering ist, die aktuelle Entwicklungslinie vorherzusehen. Insofern ist es völlig sinnvoll, Tools zu meiden, die ein schlechtes Gefühl vermitteln.
    Am einfachsten steigt man von einem Tool aus, das zum Zugunglück werden könnte, bevor man es überhaupt integriert hat

• Es geht hier zwar um die Rust-Portierung, aber sie ist noch nicht veröffentlicht.
  Es ist von „vorhersehbaren Kompatibilitäts- und Sicherheitsproblemen“ die Rede, aber auch die Zig-Version von Bun crasht ziemlich oft.
  Ich wünschte, yt-dlp hätte genauer begründet oder verlinkt, warum es vorhersehbare Kompatibilitätsprobleme geben soll. Beide Projekte haben Test-Suites, also sollte in einer idealen Welt ein schnelles Rewrite möglich sein.
  Vielleicht will man die Lage nicht weiter anheizen, aber wenn konkret gefundene Probleme existieren, würde ich sie gern sehen.
  Bun.rs hätte keine Minor-Version, sondern eher 1.4 oder 2.0 sein sollen, und Alpha-/Beta-Releases wären ebenfalls wünschenswert gewesen

  • Wenn tatsächlich ein Projekt ernsthafte Regressionen unter Bun.rs gemeldet und dazu Daten gezeigt hätte, wäre das etwas anderes.
    Aber es ist erst seit einer Woche öffentlich, und bislang sieht man kaum echte Regressionsdaten. Es wirkt eher wie bloßes „gefällt mir nicht“-Genörgel

• Diese Logik liest sich für mich kaum anders als: „libfoo wird jetzt mit emacs statt vim entwickelt, also kann man ihm nicht mehr trauen.“
  Natürlich ist es nicht exakt dasselbe, aber es fühlt sich aus einem bestimmten Grund ähnlich an.
  Die einzige Wahrheit bei Software ist, ob sie in meinem Use Case funktioniert. Auch vor AI wusste man nicht, ob der Autor streng methodisch vorgegangen ist oder einfach zufällig Dinge ausprobiert hat, bis etwas lief.
  Anders gesagt: Ich habe Software nicht danach beurteilt, welche Methodik oder welche Tools bei ihrer Entstehung verwendet wurden. Ich habe jede Menge Software benutzt, deren Test-Suite nicht existierte oder miserabel war, und Leute, die Memory Safety lieben, nutzen auch Tools in C, und umgekehrt genauso.
  Deshalb klingt die Logik „Ich mag die Art des AI-Einsatzes nicht, also benutze ich es nicht“ für mich kaum überzeugender als zu sagen, man höre auf, etwas zu benutzen, weil einem die Wahl des Editors des Autors nicht gefällt

  • Es gibt definitiv Menschen, die sich tatsächlich dafür interessieren, wie Dinge hergestellt wurden, und ihre Entscheidungen davon abhängig machen, ob sie diesem Prozess zustimmen.
    Sonst gäbe es auch keine Konzepte wie Fair-Trade-Schokolade/-Kaffee
  • Diese Analogie geht zu weit. Das ist nicht einmal dasselbe Spielfeld und nicht einmal ein angrenzendes
  • Dann gehen wir noch einen Schritt weiter: Angenommen, es gäbe einen cron job, der jeden ersten Montag im Monat die gesamte Codebasis in eine neue Sprache umschreibt — von Rust zu C++, zu Go, zu Swift und wieder zurück.
    Wäre das für Kunden des Produkts dann auch fast dasselbe wie ein Editorwechsel des Maintainers, also ein irrelevantes Detail?
  • Die meisten würden sagen, dass der verwendete Texteditor keinen nennenswerten Einfluss auf den geschriebenen Code hat.
    Aber über LLMs würden das wohl nicht viele behaupten.
    Vibe-Bun könnte genauso gut oder besser sein als das frühere Bun, aber woher sollen wir das zum jetzigen Zeitpunkt wissen?
    Und auch die Aussage „man konnte nie wissen, ob Software streng gemacht wurde, und hat sie nicht nach Methodik beurteilt“ stimmt nicht. Manche prüfen vor der Übernahme eines Projekts oder bei der Entscheidung über die weitere Nutzung durchaus, ob ein erträgliches Maß an Strenge vorhanden ist. Ich mache das bei wichtigen Dingen ebenfalls so.
    Noch mehr Menschen verlassen sich auf Reputationssignale; die sind nicht perfekt, korrelieren aber und können ausreichen — und sind viel einfacher als eine direkte manuelle Prüfung

• Wir brauchen dringend einen neuen Begriff, um die Art der LLM-Nutzung in der Entwicklungsarbeit zu beschreiben. „Vibe Coding“ hat zwar eine strenge Definition, aber gefühlt interessiert sich niemand dafür.
  Es ist wirklich schwer zu glauben, dass die Rust-Portierung zu 100 % nur „Vibe“ im ursprünglichen Sinn gewesen sein soll.
  Das Ganze ist zu einem emotionalen Schlammkampf geworden, egal ob positiv oder negativ, und wenn man „Vibe Coding“ als generellen abwertenden Begriff für LLM-Nutzung benutzt, wird es viel zu schwer, noch zu verstehen, welches konkrete Problem eigentlich gemeint ist.
  Ich selbst nutze LLMs zur Unterstützung bei der Entwicklung und mache schneller bessere Arbeit, gemessen an allen Kennzahlen, die einem Engineer wichtig sein dürften

  • Vibe Coding bedeutete ursprünglich, „sich ganz dem Vibe hinzugeben [...] und zu vergessen, dass der Code überhaupt existiert“
    https://x.com/karpathy/status/1886192184808149383
    Bei genau dieser Portierung ging es offenbar so schnell, dass ein Mensch die Validität der Übersetzung nicht überprüft hat. Ob künftig überhaupt eine manuelle Validierung stattfindet, ist ebenfalls unklar.
    Nach Dijkstras Maßstab haben allerdings schon lange vor AI die meisten Softwareprojekte „Vibe Coding“ betrieben — im Sinne von: dem Gefühl folgen und vergessen, dass Korrektheit überhaupt existiert.
    Die Korrektheit komplexen Codes sicherzustellen, ist schwer, aber in einer Welt mit 1 Milliarde Hackern im Datacenter wird das immer weniger optional werden.
    Zusatz: „Der unveröffentlichte Rust-Port von Bun enthält 13.365 unsafe-Blöcke“
    https://news.ycombinator.com/item?id=48239790
  • Im Gegensatz zu der Behauptung, mit LLMs schneller bessere Arbeit zu leisten, deuten Studien darauf hin, dass es nicht schneller sein muss und sogar langsamer sein kann.
    Die Technik ist noch so neu, dass Forschung schwierig ist, aber selbst optimistisch betrachtet zeigt die empirische Evidenz in manchen Bereichen nur etwa 3 % Verbesserung.
    Code zu schreiben ist in unserer Arbeit ohnehin selten der Flaschenhals

• Ich verstehe nicht, warum so viele Menschen sich von dieser Entscheidung derart unter Druck gesetzt fühlen. Wenn man wirklich ein Vibe-Coding-Enthusiast ist, warum vibe-codet man dann nicht einfach selbst ein besseres yt-dlp oder forkt das bestehende und passt es nach Bedarf an?

  • Ich habe oft gehört, dass Vibe Coding das Erstellen von Software so banal einfach gemacht habe, dass jeder in kürzester Zeit alles bauen könne.
    Es hieß sogar, Menschen würden für alles mögliche einmalige persönliche Software vibe-coden.
    Dann sollte es für Vibe-Coder doch keinen Grund geben, sich über irgendeine Software-Entscheidung zu beschweren. Einen persönlichen Fork zu vibe-coden, der einem besser gefällt, müsste doch kinderleicht sein. Ist das nicht das Versprechen von Vibe Coding?
  • Außerdem unterstützt yt-dlp bereits Interpreter-Plugins von Drittanbietern. Sie sagen nur, dass sie Bun nicht direkt unterstützen wollen, und die Infrastruktur dafür, dass andere nutzen können, was sie möchten, existiert bereits.
    Das ist dieses verbreitete, falsche Anspruchsdenken gegenüber Projekten, die von der Zeit und Mühe anderer getragen werden. Es ist immer wieder erstaunlich, wie Menschen für ihre gewünschten Features einfach die Zeit und Arbeit anderer verplanen wollen.
    Diejenigen, die die Arbeit machen, haben das Recht, Entscheidungen zu treffen, und wenn es einem nicht gefällt, kann man selbst forken. So funktioniert dieses Ökosystem seit jeher.
    yt-dlp lässt sich auch jetzt schon überraschend leicht anfassen
  • Für viele AI-Fans, nicht für alle, funktioniert das fast wie eine Religion. Es reicht ihnen nicht, einfach zu leben und leben zu lassen und abzuwarten, welche Art des Softwarebaus sich historisch als besser erweist; sie verlangen, dass alle ihnen zustimmen.
    Ich erlebe solche Situationen auch am Arbeitsplatz, und es macht mich wahnsinnig, dass bei AI ehrliche technische Meinungsverschiedenheiten anscheinend nicht erlaubt sind

• Ich weiß nicht recht, wie ich mich bei diesem Bun-Rewrite fühlen soll.
  Einerseits fühlt es sich sehr beängstigend an, dass der Großteil der Codebasis nicht geprüft wurde.
  Andererseits heißt es, dass die Tests mit kaum Regressionen durchlaufen.
  Vielleicht liegt das an meiner mangelnden Erfahrung in diesem Bereich, aber ich würde Tests nicht so stark vertrauen, dass ich mich völlig darauf verlasse, ohne den Code zu lesen