Wie weit ist Buns Neuschreibung in Rust?

• Die Arbeit galt als in 11 Tagen abgeschlossen, aber auch sechs Wochen nach dem Merge in main, am 27. Juli 2026, gibt es noch kein Release-Tag, und die zugehörigen Arbeiten laufen weiter
• Die erste Neuschreibung kostete vom 3. bis 14. Mai 2026 165.000 US-Dollar an Anthropic-API-Kosten, doch Buildkite-CI/CD und Folgekosten scheinen darin nicht enthalten zu sein
• Die offenen PRs von robobun stiegen von 1.277 am 9. Juli auf 2.475 am 27. Juli; wenn die Pipeline pro PR etwa 40 Minuten dauert, müsste sie 86 Tage am Stück laufen, um alle zu verarbeiten
• Mit Beginn der Neuschreibung stieg auch die Claude-Nutzung stark an, und sowohl robobun als auch Anthropic-Mitarbeiter beteiligten sich stärker an der Rust-Arbeit, sodass sich Fertigstellungszeitpunkt und tatsächliche Gesamtkosten kaum auf 165.000 US-Dollar festlegen lassen
• Da das Bun-Team weder den Abschluss der Neuschreibung noch die Gesamtkosten selbst eindeutig behauptet hat, sollte man AI-Coding-Erfolge als Grundlage für Unternehmensbewertungen nur unter Berücksichtigung von Kosten-Nutzen-Verhältnis und fortlaufendem menschlichem Eingriff betrachten

---

Die Neuschreibung geht auch nach dem Merge weiter

• Jarred Sumner erklärte in Rewriting Bun in Rust, dass er vom 3. bis 14. Mai 2026 innerhalb von 11 Tagen 165.000 US-Dollar für Anthropic-API-Aufrufe ausgegeben und das Ergebnis der Neuschreibung in main gemergt habe
  • Das entspricht rund 15.000 US-Dollar pro Tag, also einer Größenordnung, die für viele Open-Source-Maintainer kaum tragbar ist
  • Die CI/CD-Kosten, die offenbar weiterhin im Buildkite-Cluster der Organisation anfielen, scheinen in dieser Zahl nicht enthalten zu sein
• Stand 27. Juli 2026 sind seit dem Merge sechs Wochen vergangen, doch es gibt noch kein neues Release-Tag; seit dem letzten Tag bun-v1.3.14 sind sogar 11 Wochen vergangen
  • Zuvor gab es nur einmal eine Release-Pause von mehr als einem Monat: eine sechswöchige Lücke von v0.2.2 am 26. Oktober 2022 bis v0.3.0 am 7. Dezember
• Als Ersatzindikator für von Claude Code erzeugte PRs stiegen die offenen PRs von robobun von 1.277 am 9. Juli auf 2.475 am 27. Juli
  • Für Buildkite-Prüfungen und den Merge in main wurden meist etwa 40 Minuten, manchmal bis zu 1 Stunde 30 Minuten beobachtet
  • Bei 40 Minuten pro PR müsste die Pipeline 86 Tage am Stück laufen, um alle 2.475 zu mergen
  • Einige PRs haben nichts mit Rust-Code zu tun, und einzelne PRs wurden ungewöhnlich intensiv überprüft

Unterschied zwischen veröffentlichten Kosten und tatsächlichem Aufwand

• Zu Beginn der Neuschreibung nahm die Claude-Nutzung stark zu, danach war auch eine stärkere Beteiligung von Anthropic-Mitarbeitern und robobun an der Rust-Arbeit zu beobachten
  • Die Analyse setzt voraus, dass Jarred Sumners Commits während der Neuschreibung Claude genutzt haben
  • Einige PRs wurden von Anthropic-Mitarbeitern erstellt, daher sollte man nicht nur Token-Kosten, sondern auch direkten Mitarbeitereinsatz berücksichtigen
• Nimmt man an, dass die Neuschreibung weiterhin 10.000 US-Dollar pro Tag kostet, lägen die kumulierten Kosten bei fast 800.000 US-Dollar; das ist jedoch eine modellhafte Schätzung, nicht die veröffentlichten tatsächlichen Kosten
• Das Bun-Team hat nicht behauptet, dass die Neuschreibung vollständig abgeschlossen sei oder dass die Gesamtkosten nur 165.000 US-Dollar betragen hätten
  • Aus diesem Einzelfall allein lässt sich schwer ableiten, dass AI die Arbeit von Open-Source-Maintainern bereits schneller ersetzt
  • Anthropic setzt seine eigenen Tools intern ein, und sowohl automatisierte Arbeit als auch Mitarbeiterbeteiligung dauern an
• Statt AI grundsätzlich abzulehnen, warnt der Beitrag vor den aktuellen überzogenen Erwartungen und Unternehmensbewertungen und fordert zu prüfen, ob der geschaffene Wert den eingesetzten Kosten entspricht und ob die betreffende Unternehmensbewertung gerechtfertigt ist
• Anthropics C compiler und Cursors FastRender-Webbrowser hatten seit Monaten keine Commits mehr

[GN⁺]

Hacker-News-Kommentare

• Buns Rust-Rewrite läuft seit über einem Monat in Claude Code, aber fast niemand hat es bemerkt, und insgesamt funktioniert es gut
  Veröffentlicht werden soll es erst, wenn es so viele Node.js-Kompatibilitätstests besteht wie im Bun-v1.4-Video versprochen; wenn der betreffende PR gemergt wird, ist eine Veröffentlichung von v1.4 etwa nächsten Dienstag sehr wahrscheinlich

  • Für Softwarequalität darf man sich so viel Zeit nehmen, wie nötig. Ein Monat ohne Release ist keine große Sache, und wenn eine bestimmte Funktion dringend ist, kann man selbst beitragen oder einen Build erstellen
    Auch bei Node.js gibt es jedes Jahr im Dezember, abgesehen von Sicherheitsfixes, 4 bis 6 Wochen lang keine nennenswerten Releases, daher ist diese Kritik, die erst wütend gepostet wurde, ohne die Betroffenen vorher zu fragen, nicht besonders fundiert. Das sage ich als Node.js-Maintainer
  • Claude Code selbst hat Bugs und nach Releases häufig Störungen, daher ist es nicht überraschend, dass Nutzer durch die Umstellung auf Rust-basiertes Bun verursachte Bugs nicht von den üblichen Bugs unterscheiden konnten
  • Ich würde gern eine Antwort auf die im Artikel geschätzten Kosten hören, besonders auf die Buildkite-Kosten
  • Ich verstehe, warum man sich um Buns Zukunft sorgt: Viele Vibe-Coding-Projekte starten stark und werden dann wie Anthropic C vernachlässigt. Bun ist schnell und angenehm zu benutzen, also hoffe ich, dass es wie GCC lange bestehen bleibt

• Nach einem großen Refactoring oder Rewrite dauert es meist eine Weile, bis wieder das normale Entwicklungstempo erreicht wird, daher lässt sich allein aus Commit-Zahl und Release-Frequenz schwer viel ableiten
  Selbst wenn den Entwicklern die Struktur vertraut ist, müssen sie sich erst an die Rust-Codebasis gewöhnen und konzentrieren sich womöglich eher auf Dinge wie das Nachverfolgen von unsafe-Verwendungen als auf User-Features. Auch im Canary-Channel wurden kaum größere Probleme oder Veränderungen bemerkt, daher gibt es gute Gründe, aufgestaute Arbeit zu erledigen, statt überstürzt zu releasen
  Den C-Compiler von Anthropic und Cursors FastRender-Browser habe ich eher als Fähigkeitsdemonstrationen denn als dauerhafte Projekte gesehen, und ich hoffe, dass sie heute niemand direkt verwendet

  • Vor einem Monat wurden bereits alle Claude-Code-Nutzer auf die neue Version migriert, also ist es in gewissem Sinn schon ein Produktions-Release. Da das Projekt viel Aufmerksamkeit bekommt und kein Grund besteht, den offiziellen Release zu überstürzen, scheint es schrittweise vorzugehen
  • Die Perspektive der CI/CD-Kosten ist interessant. Wenn man den ROI von AI kritisiert, heißt es meist, mehr Code bedeute nicht automatisch mehr Wert, aber wenn pro CI-Lauf abgerechnet wird, steigt der tatsächliche Umsatz durchaus
    Dazu passt auch, dass CI und zusätzliche Tests entscheidend sind, um zu verhindern, dass von AI erzeugte Routinearbeit außer Kontrolle gerät
  • Selbst aus Sicht des Autors ist unklar, wie viel sich aus diesen Zahlen wirklich schließen lässt. Ich hoffe, dass Anthropic oder Bun nach dem nächsten Release eine Retrospektive mit den Gesamtkosten veröffentlichen

• Dass man mit LLMs ein Projekt in kurzer Zeit portieren oder ein Office-Produkt-Klon in einem Zug bauen kann, ist an sich beeindruckend, aber das Wesen von Software liegt nicht in schneller anfänglicher Generierung, sondern in Feature-Entwicklung und langfristiger Wartung
  Einen Word-Klon kann man mit Grundfunktionen schnell bauen, aber bei Details wie Seitenlayout, Tabellen, Bildern oder Rotation fangen LLMs bereits an zu scheitern. Selbst wenn man SQLite von C nach Rust überträgt und alle Tests besteht, ist es wahrscheinlich langsamer, weil die jahrelangen Optimierungen der bestehenden Implementierung fehlen, und man muss zudem neue Bugs durch den Sprachwechsel sowie künftigen Support schultern
  Auf Reddit tauchen ständig Projekte auf, die X, Y und Z implementiert hätten, aber Bugfixes, Nutzer-Support, Sicherheit sowie Arbeit an sich verändernden Datenstrukturen und Datenbanken sind nicht glamourös und werden deshalb oft noch schneller vernachlässigt als Vibe Coding
  Wenn man die selbst geschriebene Software nicht tief versteht, explodiert sie am Ende, und die Formulierung X in Y Tagen als Z neu geschrieben bedeutet für sich genommen gar nichts. Einen Start zu beschleunigen ist etwas völlig anderes, als portierten Code zu verstehen, weiterzuentwickeln und zu pflegen, und am Ende könnte statt der gepflegten Zig-Version nur die vernachlässigte Rust-Version plus PR-Posts die Suchergebnisse verschmutzen

  • Ich wünschte, mehr Menschen würden diesen Prozess dokumentieren. Ich lerne gerade selbst, während ich ein Projekt mit hoher LLM-Abhängigkeit baue, und es gibt einen starken Kick, wenn komplexe Features schnell funktionieren, aber Integration, Aufräumen und UI-Politur sind, nachdem man die Anfangsgeschwindigkeit erlebt hat, eher noch schmerzhafter
    Wenn der Code zu sehr aus Provisorien verknotet ist, erreicht man einen Trägheitspunkt, an dem das LLM ohne noch größeres Chaos nicht weiterkommt; dann muss man die Architektur reparieren, alles wegwerfen und neu anfangen oder bis zum letzten noch normalen Stand zurückgehen. Es ist, als würde man mit einem Jetpack entwickeln: Man kommt schnell ans Ziel, prallt aber auch schneller und schmerzhafter gegen Wände
    Hinter Debatten darüber, ob AI das Beste oder Schlimmste ist, und Wettbewerben darum, wer Tools besser nutzt, fehlen Informationen darüber, was funktioniert und was scheitert und wie man sein Verhalten bei der Nutzung ändern sollte. Ich will selbst einen Erfahrungsbericht schreiben, aber neue Features zu bauen oder UI-Macken zu beheben macht mehr Spaß, also schiebe ich es auf
  • Schon vor LLMs gab es auf GitHub Tausende verlassene Game-Engines und Compiler für Fantasiesprachen. In Betriebssystem-Foren Anfang der 2000er baute fast jeder sein eigenes OS, und einige konnten sogar Firefox ausführen
    Nicht jede Software muss kommerziell oder hochgradig ausgereift sein, um nützlich zu sein; schon Lernexperimente allein können sehr lehrreich sein
  • Je technischer es wird, desto eher gilt es als austauschbar. Dahinter steckt die Annahme in Organisationen, dass nicht man selbst oder Beziehungen, sondern reine technische Kompetenz Wert schafft
    Aber man scheint allmählich zu akzeptieren, dass auch kontingente Faktoren wie Netzwerkeffekte, Eigentum und Verantwortlichkeit wichtig sind. Zugleich steckt darin das Paradox, dass viele Techniker gerade deshalb in den Technikbereich gegangen sind, um Vetternwirtschaft, willkürlicher Bewertung und einem Umfeld zu entkommen, in dem Bluffer wichtiger sind als Technik
  • Ich habe bei einem Startup gearbeitet, das eine große Codebasis komplett neu geschrieben und dafür sogar die Feature-Entwicklung gestoppt hat; obwohl ich während des ganzen Prozesses an anderen Projekten saß und erst später zurückkam, gab es praktisch keine Lernkurve. Die Sprache hatte sich geändert, aber Kernarchitektur, Datenstrukturen und Konzepte waren dieselben
    Auch Bun wurde nicht von Grund auf neu entworfen, sondern zunächst einfach in die neue Sprache übertragen. Auch gemessen an Erfahrungen aus der Zeit vor LLMs ist es richtig, für eine schnelle Umstellung des Teams so einfach und schnell wie möglich in eine andere Sprache zu portieren, und die Rewrite-Dauer X Tage lang möglichst klein zu halten ist ein gutes Ziel
  • Die eigene Codebasis nicht tief verstehen zu wollen, ist extremer Kurzfristismus. Maintainer werden mühsam lernen, wo die Grenze zwischen AI-generiertem Code und Code liegt, den Menschen tatsächlich warten können

• Jemand habe die ursprüngliche Zig-Implementierung modernisiert, Best Practices angewandt und dabei Bugs behoben und inkrementelle Builds unter 1 Sekunde erreicht. Das deute darauf hin, dass die Probleme, die den Rewrite rechtfertigen sollten, in Wirklichkeit selbst verursacht und lösbar waren
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  Auch die Zig-Version nutzt LLMs und hat daher nichts mit einem Kulturkampf zu tun. Wer den Problembereich richtig versteht, konnte schon immer bessere Ergebnisse erzielen als jemand, der nur Ressourcen wie Tokens im Wert von Hunderttausenden Dollar hineinpumpt

  • Der Kern der Rechtfertigung für den Rewrite war nicht die Build-Geschwindigkeit, sondern Speicherfehler, die insbesondere bei der Interaktion mit durch Garbage Collection verwalteten JavaScript-Objekten entstehen. In Zig gibt es dafür generell keine Methode, das zu verhindern, und es ist auch nicht erkennbar, dass Buz das gelöst hätte
  • Dieses Projekt wirkt eher wie ein Meme oder Witz als wie ein ernsthafter Versuch. Die bestehenden 600.000 Zeilen werden als von AI erzeugter Murks bezeichnet, und es wird erklärt, dass von Menschen geschriebene Beiträge abgelehnt werden, bis die meisten Subsysteme neu geschrieben sind
    Es ist schwer, ein Projekt ernst zu nehmen, das von LLMs produzierten Murks aufräumen will und gleichzeitig menschliche Beiträge verbietet

• Dank des Bun-Rewrites sei man viel mutiger geworden, was Code-Portierungen und Rewrites sowie das Vendoring externer Abhängigkeiten angeht, und könne stärker auf interne Anforderungen zuschneiden, auch wenn das nicht zu Upstream-Projekten passt
  Gleichzeitig habe man Coding-Modellen ambitioniertere Aufgaben übertragen und sich deutlich stärker auf Test-Harnesses und Verifikation außerhalb von Sprachgrenzen konzentriert. Der Autor habe auch an mehrjährigen großen Rewrites mitgearbeitet, bewertet Bun aber als enormen Engineering-Erfolg, weil dabei Tests und funktionale Gleichwertigkeit erhalten blieben und sogar Verbesserungen hinzugefügt wurden

• Die Debatte um den Bun-Rewrite enthält viel dramatische Verdammung und persönliche Angriffe, wobei alle offenbar tiefere ideologische Anliegen hineinprojizieren. Dieser Beitrag steht der Frage skeptisch gegenüber, wie erfolgreich AI Programmierer ersetzen kann, und die Argumente des Zig-Maintainers lagen näher an Open-Source-Ethik und der Zukunft im LLM-Zeitalter
  Aus optimistischer Sicht auf AI-Fähigkeiten gibt es wenig Grund, daran zu zweifeln, dass erfahrene Entwickler modernste LLMs anleiten können, um ganze Bibliotheken zu übersetzen. Die wichtigeren Folgefragen betreffen die aktuellen Kosten und ob sich künftig Lager mit vollständiger AI-Nutzung und ohne AI-Nutzung herausbilden

  • Im Team hatte niemand Erfahrung mit Rust
  • Die Zig→Rust-Portierung von Bun liefert kaum Lehren, die sich über Zig, Rust, Sprachportierungen oder den Einsatz von LLMs verallgemeinern lassen. Die Codebasen vor und nachher haben zu viele schwer quantifizierbare Eigenschaften, und auch Vorlieben bei Sprache, Portierungsweise und LLM-Coding spielen hinein
    Wenn andere nicht dasselbe Ergebnis erzielen oder höhere Token-Kosten haben, kann man sagen, sie hätten die Tools falsch genutzt; fällt das Ergebnis enttäuschend aus, kann man ausweichen, es sei nur ein Proof of Concept gewesen und die Modelle seien in den letzten sechs Monaten besser geworden, sodass kein Vergleich möglich sei — dadurch ist es schwer, zu überprüfbaren Schlussfolgerungen zu kommen
  • Es gibt viele Gründe für Skepsis, weil LLMs hervorragend darin sind, plausibel wirkende, aber falsche Ergebnisse zu erzeugen. Diese Arbeit ist unabhängig von der Richtigkeit der Ergebnisse offenkundig ein Marketing-Event, und Anthropic hat eine Vorgeschichte mit übertriebenen oder sachlich falschen Ankündigungen, weshalb strengere Verifikation nötig ist

• Es wurde vermutet, dass sowohl die Siegesmeldung als auch selbst die aufrichtig wirkende Tiefenanalyse etwas vorschnell waren
  Das zentrale Risiko des LLM-Hypes ist, dass er erfahrenen Entwicklern, die vom Tippen und manuellen Denken erschöpft sind, sofortige Erfolge liefert, dabei aber jahrzehntelang angesammelte Software-Erfahrung aufs Spiel setzt. Die echte Rechnung kommt viel später

  • Tippen ist im Software Engineering nachrangig, aber wenn Tippen tatsächlich der Flaschenhals ist, können LLMs wertvoll sein. Solche Situationen sind allerdings selten

• Es würde die Glaubwürdigkeit erhöhen, wenn im Artikel berücksichtigt würde, dass Rust-basiertes Bun seit dem 17. Juni in Claude Code läuft und nach dem Merge in main auch als Canary-Version angeboten wurde. Für einen Rewrite dieser Größenordnung ist eine lange Canary-Phase völlig gerechtfertigt

  • Der Artikel hat die interne praktische Nutzung bei Anthropic bereits behandelt

• Anthropic hat womöglich wenig Interesse daran, die nächste Version allgemein zu veröffentlichen. Die Rust-Version läuft seit über einem Monat in Claude Code, das von Millionen genutzt wird, und womöglich war auch die Übernahme von Bun vor allem für Claude Code gedacht
  Das Open-Source-Projekt selbst könnte für sie nicht besonders wichtig sein

  • Wenn wirklich nur Claude Code wichtig wäre, wäre es viel effizienter gewesen, Claude Code selbst in Rust neu zu schreiben, statt die Sprache der TypeScript-Runtime zu ändern. Die Kosten von rund 800.000 Dollar könnten aus Anthropics Marketingbudget für große PR-Wirkung gekommen sein
  • Es ist unwahrscheinlich, dass man die breitere Community aufgibt, und je mehr andere Nutzer es gibt, desto mehr profitiert auch Anthropic. Wenn bei diesem Release Probleme auftreten, könnte es starke Kritik geben und das Vertrauen der Community beschädigt werden, daher scheint man vorsichtiger als sonst zu sein
  • Bun ist ein wichtiger Bestandteil des Web-Ökosystems, daher hat allein die Tatsache, dass Anthropic es mit AI entwickelt, einen gewaltigen PR-Effekt
  • Claude Code dürfte auf jeder JavaScript-Runtime laufen können; daher stellt sich die Frage, warum Bun überhaupt nötig war
  • Letztlich wirkt es wie ein Marketing-Event zur Werbung für Claude-basiertes Code-Rewriting. Die Botschaft, man solle Anthropic viel Geld zahlen, um eine unbequeme Codebasis loszuwerden, wurde erfolgreich vermittelt
    Wenn Claude Code das Ziel war, hätte man damit anfangen können, und wenn man ohnehin betont, dass man nicht mehr selbst Code schreibt, dürfte auch die Implementierungssprache keine Rolle spielen

• Wer schon einmal Software neu geschrieben hat, kann die aktuelle Phase verstehen. Das meiste funktioniert, aber man muss weiter korrigieren, damit es keine Regressionen gibt, und der Druck rund um einen Release ist enorm
  Die Entscheidung für den Rewrite war aus dieser Sicht richtig, aber man möchte ihn nicht von Anfang an in die Produktionsumgebung ausrollen. Wenn Jarred statt einer sofortigen Stable-Version zunächst einen Release Candidate anbietet, könnte das den Druck verringern