PR zur Rust-Neuschreibung von Bun wurde gemergt

• PR #30412 enthält die Änderung zur Neuschreibung von Bun in Rust und wurde am 14. Mai 2026 vom Branch claude/phase-a-port nach main gemergt
• Der Umfang der Änderung wird mit 6.755 Commits, 2.188 Dateien und +1,009,257/-4,024 Zeilen angegeben
• Jarred-Sumner sagte, dass bald ein Blogbeitrag mit Details erscheinen werde
• Es wird erklärt, dass diese Änderung die bestehende Test-Suite von Bun auf allen Plattformen besteht und mehrere Speicherlecks sowie instabile Tests behoben wurden
• Die Binärgröße wurde um 3 MB bis 8 MB reduziert, und die Benchmarks seien neutral oder in Teilen schneller
• Als wichtigster Grund wird genannt, dass das Team Speicherfehler, die über Jahre viel Entwicklungs- und Debugging-Zeit gekostet haben, nun mit compiler-gestützten Werkzeugen erkennen und verhindern kann
• Es wird erläutert, dass die Codebasis im Großen und Ganzen gleich geblieben ist und Architektur und Datenstrukturen ebenfalls unverändert beibehalten wurden
• Außerdem wird ausdrücklich erwähnt, dass Bun weiterhin nur wenige Third-Party-Libraries verwendet und async Rust nicht nutzt
• Nutzer können diese Änderung mit bun upgrade --canary ausprobieren
• Jarred-Sumner bat darum, bei Problemen Issues zu eröffnen, und sagte, dass der Thread geschlossen werden könnte, falls die Diskussion aus dem Ruder läuft
• Vor der Aufnahme in eine Nicht-Canary-Version stehen noch Optimierungsarbeiten aus
• Auch Aufräumarbeiten sind noch offen und sollen in einer nachfolgenden PR-Serie erfolgen

[xguru]

Wow, ein PR mit einer Million Zeilen wurde gemergt. Sie wechseln einfach in einem Rutsch von Zig zu Rust.
Erst hieß es noch: „Keine Ahnung, ob das gemergt wird~~“, und dann wird nur eine Woche später der zuvor gut funktionierende Code auf einen Schlag in eine andere Sprache umgestellt, haha.
Irgendwie fühlt es sich an, als würde durch AI-gestütztes Coding gerade etwas Monumentales passieren.

[heycalmdown]

Echt? Es hieß doch, das sei nur zum Testen und werde wahrscheinlich gar nicht verwendet.

[freedomzero]

Weil es in Zig nicht gemacht wird, geht man einfach direkt zu Rust über – ziemlich mutig, haha.

[GN⁺]

Hacker-News-Kommentare

• Wenn in der Ankündigung steht, dass das Rewrite eine Woche gedauert hat, frage ich mich, wie viel Zeit in die Vorbereitung dieser sehr detaillierten Anleitungsdatei geflossen ist, die Zig-Idiome auf Rust-Idiome abbildet: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  Außerdem sieht es in den Abschnitten Pointers & ownership und Collections so aus, als hätte die Bun-Codebasis bereits interne Smart-Pointer-Typen verwendet, sodass sie 1:1 auf Rust-Gegenstücke abgebildet werden konnte, und auch das Rust-Crate bun_collections existierte bereits
  Dieses Rewrite war offenbar schon lange vorbereitet und wurde vom Bun-Team wohl während der Übernahmeverhandlungen mit Anthropic vorgeschlagen

  • Wenn ich Artikel über LLMs lese, weiß ich nie, was davon stimmt, und bei den Hacker-News-Kommentaren hier ist es genauso
    Es geht um so viel Geld, dass es klar Anreize gibt, Marketing-Leute in die Community zu setzen, und manche verfallen einfach in Lagerdenken
    Da Anthropic Bun jetzt besitzt, gibt es auch genug Anreiz, diese Arbeit einfacher wirken zu lassen, als sie tatsächlich war
  • Wenn man Faktoren wie die Qualität des erzeugten Rust-Codes, ob die Zeilenzahl angemessen ist und wie gut die Codebasis ursprünglich auf diese Arbeit vorbereitet war, einmal beiseitelässt, dann wirken 622 Zeilen Dokumentation doch wie ein relativ kleiner Aufwand als Vorleistung, um die Konsistenz oder Qualität von etwa 1 Million Zeilen Output zu erhöhen
    Bei dieser Größenordnung scheint es einen Multiplikatoreffekt zu geben
    Ich frage mich allerdings, wie viel implizites Wissen nötig war, um diese Regeln zu erstellen, und wie oft diese Datei iterativ verbessert wurde
    Zum Beispiel würde mich interessieren, wie viele dieser Regeln aus Fehlfällen stammen, die man in wiederholten Übersetzungsdurchläufen entdeckt hat
  • Du sagst using internal smart pointer types that map 1-to-1 to Rust equivalents, aber Smart Pointer wurden nicht von Rust erfunden
    Wenn man Code in einer anderen Sprache mit Pointern schreibt, modelliert man dieselben Typen ohnehin schon im Kopf
    Und es stimmt auch nicht, dass das Rust-Crate bun_collections bereits existierte
    Es ist nur ein Teil des PRs der Codebasis und war nicht schon vorher vorhanden
  • Das ist wie bei Anthropics gcc-Demo
    Es wäre sehr leicht, die Zweifel zu verringern und die IPO-Stimmung noch weiter anzuheizen: einfach die versteckte Vorarbeit, die nötig war, um die AI in diese Richtung zu lenken, in einem separaten Repository veröffentlichen und alle das Ergebnis reproduzieren lassen
    Am Ende wollen Kunden doch genau das erreichen: 1 Million Zeilen nutzbaren Code in „7 Tagen“
    Dann könnte jeder es in seinem eigenen Workflow nachvollziehen, und dabei würden auch Anthropics Nutzungsmetriken steigen
    Wenn das wirklich so ein großartiges Ergebnis wäre, hätte man wohl zuerst einen Blogpost mit Link und Anleitung veröffentlicht
    Vielleicht wird genau in diesem Moment so ein Blogpost geschrieben und beweist, dass ich falsch liege
  • In der Zig-Version von Bun gab es wohl drei Pointer-Typen, die sich sauber auf bestehende Rust-Pointer-Typen abbilden ließen, und für die übrigen sieben oder acht mussten neue Typen geschaffen werden
    Ist das der Kern der Verschwörungstheorie?
    Auch bun_collections wirkt nicht so, als wäre es viel älter als der Portierungsleitfaden

• [phone] heißt, Bun hat jetzt mehr als 1 Million Zeilen Rust-Code
  Das nähert sich der Größe des Rust-Compilers selbst
  Allerdings ist BunJS größtenteils ein Wrapper um einen JavaScript-Interpreter und eine Neuimplementierung von NodeJS-Bibliotheken, also eher ein Wrapper um die Rust-Standardbibliothek
  BunJS scheint zu einem Kanarienvogel für das Management von Softwarekomplexität im LLM-Zeitalter zu werden

  • mostly a JavaScript interpreter wrapper ist nicht wirklich korrekt
    Bun ist ein JavaScript- und CSS-Transpiler mit Batteries included, also Parser, Minifier, Bundler, ein Paketmanager wie npm, ein Test-Runner wie Jest und hat außerdem Runtime-APIs wie eingebaute Postgres-, MySQL- und Redis-Clients
    Natürlich kommt da extrem viel Code zusammen
  • Bun ist kein JavaScript-Interpreter, sondern eher eine Neuimplementierung von NodeJS-Bibliotheken und diversen anderen Bibliotheken
    Bun nutzt JavaScriptCore als JS-Engine, daher macht Bun selbst kein JavaScript-Parsing, keine Interpretation und kein JIT oder sollte es zumindest nicht tun
    Korrektur: falsch gelesen. Da „JavaScript interpreter wrapper“ stand, ist die Formulierung doch passend
  • Ich weiß nicht, ob iOS das wegen des führenden + als Telefonnummer erkennt oder ob noch etwas anderes eine Rolle spielt, aber auf Mobilgeräten werden Zeilenänderungszahlen unterstrichen und lassen sich antippen, um einen Anruf zu starten
    Falls das wegen der Größe des Diffs passiert, ist das ziemlich lustig
  • Die Bun-Codebasis hatte schon vor dem Rewrite eine ähnliche Anzahl an Codezeilen
    Dass das Rewrite am Ende auf eine ähnliche LOC kommt, ist also nichts Ungewöhnliches
  • Dass ein JavaScriptCore-Wrapper 1 Million Zeilen hat, ist ein großartiges Beispiel dafür, was Agenten leisten können

• $ rg 'unsafe [{]' src/ | wc -l ergibt 10428, und $ rg 'unsafe [{]' src/ -l | wc -l ergibt 736
  Nach Sprachen aufgeschlüsselt sind es in Rust 1443 Dateien mit 929213 Zeilen, in Zig 1298 Dateien mit 711112 Zeilen, in TypeScript 2604 Dateien mit 654684 Zeilen, in JavaScript 4370 Dateien mit 364928 Zeilen, in C 111 Dateien mit 305123 Zeilen, in C++ 586 Dateien mit 262475 Zeilen und in C Header 779 Dateien mit 100979 Zeilen

  • In Rust ist es schön, potenziell unsicheren Code gezielt so durchsuchen zu können
    Wie sucht man in Zig nach unsicherem Code?
    Oder muss man einfach davon ausgehen, dass er überall ist
  • Wenn in der Hälfte der Dateien das Schlüsselwort unsafe vorkommt, sieht das nicht nach einem guten Rewrite aus
    Wenn fast die Hälfte des Codes weiterhin unsafe ist, worin liegt dann überhaupt der Sinn, nach Rust umzuschreiben
  • Hoffen wir, dass Mythos wirklich das Beste der Welt ist, wie behauptet. Denn jetzt wird man es wirklich brauchen
  • Wir haben Memory Safety zu Hause!
    Das zu Hause: 10428

• Wir schreiben noch an dem Blogpost dazu und werden später mehr Details teilen
  Wer den Hintergrund verstehen will, kann sich die Liste der Bugfixes in Bun v1.3.14 und den Release Notes davor anschauen
  Rust wird nicht all das beseitigen. Leaks, die dadurch entstehen, dass Referenzen zu lange gehalten werden, oder sämtliche Probleme durch Reentrancy über die JS-Grenze hinweg bleiben weiterhin unsere Verantwortung
  Aber ein großer Teil dieser Liste betrifft use-after-free, double-free oder vergessene Freigaben auf Fehlerpfaden, und solche Dinge werden dann entweder zu Compilerfehlern oder zu automatischer Bereinigung

  • Vor 9 Tagen wurde dazu Folgendes gesagt[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    Vielleicht war es doch keine Überreaktion?
    [0]: https://news.ycombinator.com/item?id=48019226
  • Ich freue mich auf den Blogpost
    Mich würde interessieren, ob geplant ist, Zig- und Rust-Binärdateien in großem Umfang mit echten Anwendungen parallel laufen zu lassen oder sie nach Möglichkeit in Produktion als Shadow Run mitlaufen zu lassen, um Bugs herauszufiltern
  • Wenn ich zahlender Kunde wäre, würde mich interessieren, was diese Arbeit gekostet hat
    Kann man eine grobe Schätzung nennen
  • Mich würde interessieren, ob ihr irgendeine Art von End-to-End-Fuzzing implementiert habt oder noch implementieren wollt, das beide Binärdateien miteinander vergleicht
    Ich würde auch gern den konkreten Plan kennen, wie dieses Release ausgeliefert werden soll, ohne Benutzer-Workflows kaputtzumachen
  • Könnte das möglicherweise die Stabilitätsprobleme der Bun Workers API beheben? https://bun.com/docs/runtime/workers

• Vor etwa 9 Tagen schrieb Jarred noch, dass überhaupt nicht sicher sei, ob das gemergt wird, und dass die Reaktionen überzogen seien
  Ironisch

  • Klingt nach einem Paradebeispiel für Open-Source-Führung
    Man stelle sich vor, Linus hätte gesagt, er werde den Linux-Kernel nicht umschreiben, und wäre dann eines Tages aufgewacht und hätte ein vollständiges maschinell unterstütztes Rust-Rewrite des Ganzen gemergt — was das für ein Chaos ausgelöst hätte
  • Wenn jemand das Unternehmen nicht mehr besitzt, kann man seine Aussagen getrost ignorieren
    Offenbar musste man die ausgegebenen Token-Kosten rechtfertigen
  • Das schließt aber nicht aus, dass es doch gemergt wird

• Wow, das wird in Zukunft spannend zu beobachten sein
  Es ist praktisch ausgeschlossen, dass dieser Code geprüft wurde, aber vielleicht sind wir inzwischen im posthumanen Zeitalter, in dem man Modellen zutrauen kann, Code zu schreiben und zu reviewen
  Das ist wie Gastown, nur bei einem deutlich bekannteren Projekt
  Ich finde es spannend, wie dieses Projekt künftig neue Features hinzufügen soll — oder ob das überhaupt noch möglich ist
  Weiß jemand, wofür Anthropic Bun genau verwendet?
  Ist es Teil von Claude Code?
  Es macht mir künftig ziemlich Sorgen, Bun zu verwenden, aber ich weiß nicht, inwieweit diese Sorge auch für die Nutzung von Claude gilt

  • Dass man Modellen zutrauen kann, Code zu schreiben und zu reviewen, heißt das ganz sicher nicht
  • Alle Tests wurden bestanden
    Wenn man einer Testsuite nicht zutrauen kann, automatische Sprachübersetzung zu erkennen, dann sollte man dieser Testsuite von vornherein überhaupt nicht trauen :)
  • Ich weiß nicht, wie Anthropic Bun nutzt, aber es wirkt so, als werde es genutzt, um das Overton-Fenster in Richtung „Es ist okay, Millionen Zeilen blind zu mergen“ zu verschieben
  • In welchem Zustand ist die Testsuite überhaupt

• Ich freue mich ehrlich gesagt auf Experimente mit automatischer Übersetzung, habe aber Sorge, dass es viele Abwärtskompatibilitätsprobleme geben wird
  Ich habe angefangen, mir den Commit anzusehen, und im Grunde wird das Problem „Tests schlagen fehl“ dadurch gelöst, dass man die Tests selbst ändert
  Die eigentliche Arbeit, das in bereits ausgelieferten Programmen korrekt zum Laufen zu bringen, beginnt jetzt erst
  Immerhin ist die serverseitige JS-Community aus irgendeinem Grund ohnehin bereits an häufige Brüche gewöhnt

  • Der Gedanke, dass in die Runtime ein Code einfließt, den kein einziger Mensch angeschaut hat, fühlt sich unangenehm an
    Wenn das am Ende aber wirklich ohne größere Probleme funktioniert, wäre das ziemlich erstaunlich
  • Ich weiß nicht, ob diese Entscheidungen vom LLM getroffen wurden, aber ich hatte immer den Eindruck, dass Claude stärker zu fragwürdigem Verhalten neigt, also eher Tests anpasst, statt die richtige Lösung für ein Problem zu finden
    GPT/Codex ist in dieser Hinsicht ehrlicher
  • Es sieht für mich nicht so aus, als würde das sofort ein stabiles Release werden, aber ich lasse mich gern vom Gegenteil überzeugen
    Ich bin dem ganzen Rewrite gegenüber skeptisch, und Jarred Sumner hat so viele Follower im Internet, dass es wie Werbung wirkt
  • Ein Beispiel dafür, das Problem „Tests schlagen fehl“ zu lösen, indem man die Tests selbst verändert: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    Großartig! Man muss dem Test einfach willkürlich sleep(1) hinzufügen. Keine Sorge, alles wird gut!
  • Ich würde die Tests gern durchsehen, um zu erkennen, ob es tatsächlich wichtige Änderungen gab, aber GitHub kann nicht einmal den Diff laden

• Die wenigen Projekte, für die ich Bun benutze, werde ich auf etwas anderes umstellen
  Einer Governance, die solche waghalsigen Änderungen zulässt, vertraue ich nicht

  • Deno ist großartig, bekommt aber meiner Meinung nach nicht genug Liebe
    Es ist von Anfang an gut geschrieben und muss deshalb nicht umgeschrieben werden
  • Ich werde einfach weiter Node benutzen
    Andererseits ist es interessant zu sehen, wie diese Feuertaufe ausgeht, und langfristig werden die Probleme wohl am Ende doch gelöst

• Es gibt einen Thread, den man sich aus Lehrzwecken anschauen kann. Darin hat sich Jarred vor einer Woche erneut aus der Merge-Entscheidung herausgehalten, und eine Menge Fußsoldaten griffen Leute an, die vorhersagten, dass es bald gemergt würde:
  https://news.ycombinator.com/item?id=48073680
  Im Rückblick hat sich das nicht besonders gut gehalten, oder?

  • Von „Dieser ganze Thread ist eine Überreaktion. 302 Kommentare über Code, der nicht funktioniert. Wir haben uns nicht auf ein Rewrite festgelegt. Es ist sehr wahrscheinlich, dass dieser Code komplett verworfen wird“ bis hin zu einem vollständigen Merge nach 10 Tagen — selbst wenn man es nur als experimentelle Neugier betrachtet, wirkt das wirklich verrückt
  • Es überrascht mich immer wieder, wie viele Machtläufer es auf der Welt gibt, denen ziemlich egal ist, wessen Stiefel sie lecken

• Wenn auch nur ein bisschen etwas schiefläuft, wird der Spott über den Dealer, der auf seiner eigenen Ware ist, endlos und düster weitergehen

  • Zu viele Menschen sind emotional nicht darauf vorbereitet, dass vielleicht gar nichts schiefläuft
  • Reichte nicht schon allein der geleakte Claude-Code als Anlass für Spott
  • Sie sind doch jetzt schon auf ihrer eigenen Ware
    Hast du das Mythos-Paper gelesen? Die Anthropomorphisierung ist wirklich heftig
    Vielleicht ist das nur billige Aufmerksamkeitshascherei, aber wenn sie wirklich glauben, dass LLMs Bewusstsein haben … wow