Buns Rust-Neuentwicklung nach der Übernahme durch Anthropic: 22 Millionen monatliche Downloads erhöhen den Druck

Bun hat nach der Übernahme durch Anthropic seine Neuentwicklung in Rust abgeschlossen. Damit bildet nun eine KI-generierte Codebasis das Fundament für mehr als 22 Millionen monatliche CLI-Downloads.

Die Änderung ist weit mehr als eine routinemäßige Migration der Programmiersprache. Laut Bun half Claude dabei, mehr als 500.000 Zeilen Zig in rund eine Million Zeilen Rust zu übertragen. Der intensive Portierungsprozess dauerte 11 Tage.

Diese Geschwindigkeit sorgt für Schlagzeilen, doch die eigentliche Geschichte ist die Zuverlässigkeit. Bun unterstützt inzwischen Claude Code, OpenCode, Prisma Compute und Entwickler, die von ihrer Infrastruktur ein vorhersehbares Verhalten erwarten. Die Neuentwicklung wirft die Frage auf, ob Compiler-Prüfungen, automatisierte Reviews und eine gewaltige Testsuite KI-generierten Systemcode vertrauenswürdig machen können.

Zugleich führt sie zu einer unbequemen Umkehrung. Zig ermöglichte es einem einzelnen Entwickler, Buns breiten Funktionsumfang innerhalb eines Jahres aufzubauen. Eben diese Vielfalt führte später zu Speicherlecks, Use-after-free-Fehlern und wachsendem Wartungsdruck, den Bun nun mit Rust reduzieren möchte.

Buns Rust-Neuentwicklung nach der Übernahme durch Anthropic verändert das Risikoprofil

Bun wechselte die Sprache nicht, um sich mit einem angesagten Etikett zu schmücken. Der Wechsel erfolgte, weil wiederkehrende Speicherfehler zu einer betrieblichen Belastung geworden waren.

Bun vereint eine JavaScript-Laufzeitumgebung, einen Paketmanager, einen Bundler, einen Transpiler, einen Test Runner und Implementierungen zahlreicher Node.js-APIs. Dieser Umfang bietet Entwicklern ein einziges Werkzeug für Aufgaben, die normalerweise mehrere Pakete erfordern.

Er schafft jedoch auch zahlreiche Schnittstellen zwischen JavaScript und nativem Code. JavaScript nutzt Garbage Collection, wodurch nicht mehr erreichbare Objekte automatisch freigegeben werden. Buns native Komponenten müssen diese Objekte mit dem Speicher koordinieren, der von hardwarenäherem Code verwaltet wird.

Diese Koordination entwickelte sich zu einer dauerhaften Fehlerquelle. Bun-Gründer Jarred Sumner führte kürzlich Defekte auf, darunter Abstürze durch Use-after-free, doppelte Freigaben, Zugriffe außerhalb zulässiger Speicherbereiche, Race Conditions und nicht freigegebenen Speicher.

Ein Use-after-free tritt auf, wenn Software auf Speicher zugreift, nachdem dieser freigegeben wurde. Die Folgen reichen von einem Absturz über unvorhersehbares Verhalten bis hin zu einer Sicherheitslücke.

Bun v1.3.14 behob entsprechende Fehler unter anderem in Komprimierungsstreams, HTTP/2-Verbindungen, UDP-Sockets, Puffern, Kryptografiefunktionen, TLS-Sitzungen, Datei-Wächtern und im CSS-Parser. Dabei handelte es sich nicht lediglich um mehrere Varianten eines einzelnen, isolierten Fehlers.

Mehrere Probleme traten auf, wenn JavaScript-Callbacks den Zustand nativen Codes zu einem unerwarteten Zeitpunkt veränderten. Andere entstanden, weil Bereinigungscode nicht, doppelt oder nach einer fehlgeschlagenen Speicherzuweisung ausgeführt wurde.

Bun setzte bereits mehrere Schutzmaßnahmen ein. Das Team passte den Zig-Compiler an, um AddressSanitizer zu unterstützen, ein Laufzeitwerkzeug zur Erkennung ungültiger Speicherzugriffe. Das Projekt führte diese Prüfungen bei jedem Commit aus.

Außerdem nutzte das Team kontinuierlich Fuzzilli. Fuzzilli erzeugt ungewöhnliche JavaScript-Programme, um Fehler in Engines und Laufzeitumgebungen aufzudecken, die normale Tests möglicherweise übersehen.

Diese Systeme fanden Fehler, nachdem der Code bereits geschrieben worden war. Sumner wollte ein Programmiermodell, das mehr Fehler bei der Speicherverantwortung schon während der Kompilierung zurückweist.

Rusts Ownership-System verfolgt, welcher Teil eines Programms die Kontrolle über einen Wert hat. Der Borrow Checker erzwingt Regeln für Referenzen, während Drop automatisch Bereinigungsarbeiten ausführt, sobald ein Wert seinen Gültigkeitsbereich verlässt.

Safe Rust macht viele Use-after-free- und Double-free-Muster zu Compilerfehlern. Dadurch erhalten Entwickler früher Rückmeldung als durch Fuzzing, Continuous Integration oder Absturzberichte aus dem Produktivbetrieb.

Buns Rust-Neuentwicklung verändert somit den Punkt, an dem das Team Fehler zu erkennen erwartet. Manche Fehler sollten die Entwicklung nun stoppen, bevor überhaupt eine Binärdatei ausgeführt wird.

Die Migration folgt auf die Übernahme von Bun durch Anthropic am 3. Dezember 2025. Anthropic erklärte, Bun habe sich zu einer wichtigen Infrastruktur für Claude Code entwickelt, das im November desselben Jahres einen bedeutenden Umsatzmeilenstein erreicht habe.

Die offizielle Ankündigung zur Übernahme von Bun verknüpfte die Laufzeitumgebung unmittelbar mit Anthropics Strategie für Programmierwerkzeuge. Diese Verbindung erhöht die Kosten möglicher Instabilität.

Laut Bun verzeichnet seine Kommandozeilenschnittstelle monatlich mehr als 22 Millionen Downloads. Vercel, Railway und DigitalOcean bieten zudem Unterstützung aus erster Hand für die Laufzeitumgebung.

Downloadzahlen entsprechen nicht der Zahl aktiver Entwickler, Produktivbereitstellungen oder eindeutiger Rechner. Automatisierte Builds können dasselbe Paket wiederholt herunterladen. Dennoch verdeutlicht die Zahl die Größe der Verbreitungsfläche, die Bun unterstützen muss.

Die erste Rust-Version ist nicht bloß eine neue Implementierung hinter einem Nischenexperiment. Sie bildet die Grundlage für Werkzeuge, die innerhalb von Repositorys, Build-Systemen und Deployment-Pipelines arbeiten.

Damit wird Buns Rust-Neuentwicklung nach der Übernahme durch Anthropic zu einem Test zweier Versprechen. Rust soll verbreitete Speicherfehler verhindern, während Claude eine andernfalls kaum praktikable Migration wirtschaftlich möglich machen soll.

Die Neuentwicklung wird daran gemessen werden, ob beide Versprechen dem Produktiveinsatz standhalten.

22 Millionen monatliche Downloads machen Stabilität zum Produkt

Bei Buns heutiger Größenordnung ist Zuverlässigkeit kein nachrangiges Entwicklungsziel mehr. Sie ist Teil des Produkts, das Entwickler installieren.

Bun begann als Sumners zeilenweise Portierung des JavaScript- und TypeScript-Transpilers von esbuild von Go nach Zig. Seinen ersten Zig-Code schrieb er im April 2021.

Die Entwicklung der ursprünglichen Version dauerte etwa ein Jahr. Sumner führt dieses Tempo auf die Einfachheit und die hardwarenahe Kontrolle von Zig zurück, die dies ermöglicht hätten, bevor moderne Programmiermodelle verfügbar waren.

Dieser Ursprung ist wichtig, denn die Neuentwicklung erklärt weder Rust noch Zig zum eindeutigen Sieger. Zig ermöglichte es Bun, mit einem ungewöhnlich breiten Funktionsumfang auf den Markt zu kommen.

Anschließend übernahm Bun immer mehr Aufgaben, wodurch die manuelle Verwaltung von Lebenszeiten zunehmend aufwendig wurde. Die Laufzeitumgebung bindet JavaScriptCore, die von Safari verwendete Engine, sowie mehrere C- und C++-Bibliotheken ein.

Zu diesen Abhängigkeiten gehören Komponenten für Netzwerke, Verschlüsselung, Datenbanken und Komprimierung. Etwa ein Fünftel der früheren Bun-Codebasis war bereits in C++ geschrieben.

Rust kann diese externen Bibliotheken nicht automatisch sicher machen. Foreign Function Interfaces, kurz FFI-Schnittstellen, verbinden Rust mit Code, dessen Speicherregeln der Compiler nicht vollständig überprüfen kann.

Rust kann diese Interaktionen jedoch in ausdrücklich als unsafe gekennzeichneten Abschnitten bündeln. Entwickler können so erkennen, wo die üblichen Garantien des Compilers nicht mehr gelten.

Die Sprache sorgt außerdem für eine einheitlichere routinemäßige Bereinigung. In Zig setzen Entwickler üblicherweise an einzelnen Aufrufstellen, an denen eine Ressource freigegeben werden muss, defer ein.

Dieses explizite Modell gibt Entwicklern Kontrolle, erfordert aber konsequente Wiederholung. Seltene Fehlerpfade können die Bereinigung überspringen oder sie versehentlich doppelt ausführen.

Rusts Drop-Mechanismus bindet die Bereinigung an die Lebenszeit eines Objekts. Laut Bun trug diese Änderung bereits dazu bei, Speicherlecks im Zusammenhang mit Dateipfaden und Build-Daten zu beheben.

In einem internen Test wurde ein Projekt mit 60 Modulen wiederholt innerhalb desselben Prozesses gebündelt. Bun berichtete, dass v1.3.14 bei jedem Build etwa drei Megabyte Speicher verlor.

Nach 2.000 Builds belegte die Zig-Version in Buns Test 6.745 Megabyte. Die Rust-Implementierung stabilisierte sich laut dem Unternehmen bei 609 Megabyte.

Dieser Vergleich wurde bislang nicht unabhängig mit unterschiedlichen Arbeitslasten reproduziert. Dennoch veranschaulicht er die Art von Fehler, die Bun beseitigen will.

Ein Entwicklungsserver könnte den Code nach jeder Anfrage oder Dateiaktualisierung neu erstellen. Selbst ein kleines Speicherleck wird problematisch, wenn der Prozess tagelang läuft.

Dasselbe gilt für Coding Agents. Claude Code kann beim Untersuchen von Dateien, Ausführen von Befehlen und Ändern eines Repositorys wiederholt unterstützende Prozesse starten.

Ein Fehler der Laufzeitumgebung kann den Agenten unterbrechen, ein Zwischenergebnis beschädigen oder dazu führen, dass Entwickler die Infrastruktur statt ihrer Anwendung debuggen müssen.

Claude Code wechselte auf die Rust-Portierung, bevor Bun 1.4 allgemein veröffentlicht wurde. Laut Bun nutzte die am 17. Juni veröffentlichte Claude-Code-Version 2.1.181 die neue Implementierung.

Buns Produktivtelemetrie zufolge sank die mediane Startzeit unter Linux von 517 auf 464 Millisekunden. Das entspricht einer Verbesserung von etwa 10 Prozent.

Geschwindigkeit war nicht das Hauptziel. Bedeutsamer war die Aussage, dass die meisten Nutzer den Sprachwechsel nicht bemerkten.

Unsichtbare Infrastrukturmigrationen sind häufig erfolgreiche Migrationen. Anwendungen sollten ihr bisheriges Verhalten beibehalten, während sich Wartbarkeit und Zuverlässigkeit im Unterbau verbessern.

Prisma lieferte einen weiteren frühen Praxistest. Seine serverlose Datenbankplattform nutzte die Rust-Neuentwicklung für die öffentliche Betaversion von Prisma Compute.

Prisma erklärte, die frühere Implementierung habe Speicherlecks aufgewiesen und ihren Verbindungspool nach dem Anhalten und Fortsetzen einer virtuellen Maschine nicht wiederherstellen können. Die Entwickler testeten diese Szenarien erneut mit der Portierung.

Die neue Implementierung bewältigte laut Prismas Bewertung des Produktiveinsatzes diese konkreten Fehlerszenarien. Prisma wies zugleich darauf hin, dass unsicherer Code weiterhin Audits und menschliche Reviews erfordere.

Diese Kombination verdeutlicht die Tragweite besser als die Downloadzahl allein. Die Portierung hat messbare Verbesserungen hervorgebracht, doch Vertrauen in den Produktiveinsatz erfordert mehr als erfolgreiche Demonstrationen.

Auch Node.js und Deno geraten durch Buns Fortschritte unter Druck, obwohl keines der beiden Projekte der zentrale Gegenspieler in dieser Geschichte ist. Node.js bleibt der Kompatibilitätsmaßstab für serverseitiges JavaScript.

Deno nutzt bereits Rust rund um die JavaScript-Engine V8. Seine Architektur bietet einen relevanten Vergleich für die Verwaltung einer JavaScript-Laufzeitumgebung mit Rust und nativen Abhängigkeiten.

Bun muss die Kompatibilität mit Node.js wahren und zugleich seine Leistungsversprechen sowie sein breiteres Werkzeugspektrum aufrechterhalten. Eine Neuentwicklung, die Abstürze reduziert, aber Verhaltensunterschiede einführt, würde lediglich ein Zuverlässigkeitsproblem gegen ein anderes austauschen.

Das Team entschied sich daher für eine mechanische Portierung statt einer sofortigen Neugestaltung. Der neue Rust-Code ähnelt bewusst der bisherigen Zig-Architektur.

Diese Entscheidung verringerte Verhaltensänderungen während der Migration. Sie übernahm jedoch auch alte Annahmen und hardwarenahe Muster in eine Sprache mit anderen Sicherheitsregeln.

Daraus entsteht die zentrale Spannung des Projekts. Bun entschied sich wegen der stärkeren Garantien für Rust, doch der sicherste Weg zur Kompatibilität bewahrte zunächst erhebliche Mengen an unsicherem Code.

Claude ersetzte eine einjährige Neuentwicklung durch eine elftägige Verifizierungsschleife

Der bemerkenswerte Mechanismus war nicht die reine Codegenerierung. Es war ein kontrollierter Kreislauf, der Implementierung, Kritik, Korrektur und Tests voneinander trennte.

Bun schätzte, dass eine herkömmliche Neuentwicklung drei erfahrene Entwickler etwa ein Jahr lang beschäftigen würde. In diesem Zeitraum würden neue Funktionen und Kompatibilitätsverbesserungen langsamer vorankommen oder ganz ausgesetzt.

Die bestehende Zig-Codebasis umfasste ohne Kommentare 535.496 Zeilen. Eine manuelle Portierung hätte außerdem einen langlebigen Branch geschaffen, der sich kontinuierlich von der Produktivversion entfernt hätte.

Sumner testete stattdessen ein noch nicht veröffentlichtes Anthropic-Modell namens Claude Fable 5. Er verbrachte etwa drei Stunden damit, Regeln für die Übertragung von Zig-Mustern, -Typen und -Lebenszeiten nach Rust zu entwickeln.

Claude dokumentierte diese Entscheidungen in einem Portierungsleitfaden. Ein zweites generiertes Dokument ordnete den Feldern der gesamten Codebasis ihre erwarteten Lebenszeiten zu.

Das Team begann mit drei Dateien, statt sofort alles zu übersetzen. Jeweils eine Claude-Instanz implementierte eine Portierung, zwei separate Instanzen prüften sie und eine weitere nahm Korrekturen vor.

Diese Trennung war beabsichtigt. Ein Modell, das eine Änderung erstellt hat, könnte dazu neigen, seine eigene Argumentation weiterhin unkritisch zu akzeptieren.

Die prüfenden Instanzen erhielten den Diff ohne den vollständigen Kontext der implementierenden Instanz. Ihre Aufgabe bestand darin, nach fehlerhaftem Verhalten und Regressionen zu suchen.

Sumner bezeichnete dies als adversariales Review. Es ähnelt einer unabhängigen Codeüberprüfung, allerdings waren alle Beteiligten Instanzen derselben Modellfamilie.

Der gesamte Vorgang umfasste etwa 50 dynamische Claude Code-Workflows. In Spitzenzeiten liefen vier Workflow-Gruppen gleichzeitig, die jeweils 16 Claude-Instanzen koordinierten.

Damit arbeiteten ungefähr 64 Agenten parallel. Der Port erreichte Berichten zufolge eine Spitzenleistung von rund 1.300 generierten Zeilen pro Minute.

Von Beginn an verlief der Prozess nicht reibungslos. Agenten, die im selben Repository arbeiteten, verwendeten widersprüchliche Git-Befehle, darunter Stash-Operationen und einen Hard Reset.

Sumner änderte ihre Anweisungen und untersagte weitreichende Git-Operationen. Schließlich nutzte das System vier getrennte Worktrees; die Agenten committeten gezielt einzelne Dateien und tauschten Ergebnisse über Branches aus.

Dieses Scheitern ist bedeutsam, weil es zeigt, dass die Fähigkeiten des Modells allein die Neuentwicklung nicht ermöglichten. Der Workflow erforderte ausdrückliche Beschränkungen für gemeinsam verwalteten Zustand und destruktive Aktionen.

Teams, die ähnliche Migrationen erwägen, benötigen ebenso klare operative Regeln. Ein Agent kann korrekten Code schreiben und dennoch Arbeit beschädigen, wenn er unsachgemäß mit Repositories, Zugangsdaten, Build-Systemen oder Deployment-Werkzeugen umgeht.

Die Migration erzeugte ohne Merge-Commits 6.502 Commits; Bun meldete für den elftägigen Zeitraum insgesamt 6.778 Commits. Der übernommene Diff fügte etwas mehr als eine Million Zeilen hinzu.

Diese Zahlen beschreiben Aktivität, nicht Qualität. Kleine Commits können die Nachvollziehbarkeit verbessern, doch Tausende automatisierte Commits überfordern auch herkömmliche menschliche Review-Prozesse.

Bun stützte sich vor allem auf Compiler, automatisierte Reviewer und seine bestehende Testsuite. Diese umfasste plattformübergreifend rund eine Million Assertions.

Vor dem Merge meldete das Team in der Continuous Integration eine Testabschlussquote von 100 Prozent. Nach eigenen Angaben wurden keine Tests gelöscht oder übersprungen.

Unter Debian verzeichnete Bun 1.386.826 expect()-Aufrufe in 60.624 Tests. Unter macOS und Windows wurden jeweils mehr als eine Million Assertions ausgeführt.

Eine in TypeScript geschriebene Testsuite verschaffte Bun einen wichtigen Vorteil. Die Tests prüften das beobachtbare Verhalten, ohne davon abhängig zu sein, ob die zugrunde liegende Runtime Zig oder Rust verwendete.

Diese Architektur machte einen mechanischen Port messbar. Jede übersetzte Komponente musste weiterhin die Ergebnisse liefern, die dieselben externen Tests bereits erwarteten.

Claude verarbeitete außerdem Compilerfehler als Arbeitswarteschlange. Bun teilte den Rust-Code in etwa 100 Crates auf, also separat kompilierte Pakete innerhalb eines Rust-Projekts.

In einer Phase erzeugte cargo check etwa 16.000 Fehler. Die Workflows gruppierten diese Fehler nach Crate, wiesen sie Agenten zu, überprüften die Korrekturen und wiederholten den Prozess.

Die Kompilierungsschleife verwandelte eine einschüchternde Migration in klar begrenzte Aufgaben. Jeder Fehler lieferte lokales Feedback, auf das ein Agent unmittelbar reagieren konnte.

Dieser Ansatz funktionierte besonders gut, weil der Rust-Compiler viele Fehler bei Ownership und Typen präzise erläutert. Der Compiler wurde sowohl zur Kontrollinstanz als auch zur Quelle strukturierter Anweisungen.

Vor dem Merge verbrauchte der Prozess 5,9 Milliarden nicht zwischengespeicherte Eingabe-Token und 690 Millionen Ausgabe-Token. Zusätzlich wurden 72 Milliarden zwischengespeicherte Eingabe-Token gelesen.

Bun schätzte die Gesamtkosten auf Grundlage der API-Preise auf etwa 165.000 US-Dollar. Darin sind nicht sämtliche organisatorischen Kosten enthalten, etwa für die ursprüngliche Codebasis, Tests, menschliches Fachwissen oder die spätere Wartung.

Der Vergleich mit drei Ingenieuren, die ein Jahr lang arbeiten, ist daher eher richtungsweisend als vollständig. Claude erschuf Buns Architektur, Kompatibilitätsarbeit oder Testkorpus nicht aus dem Nichts.

Das System nutzte über Jahre angesammelten Entwicklungskontext. Die Geschwindigkeit der Migration hing davon ab, dass dieser Kontext in Formaten verfügbar war, die Agenten lesen und validieren konnten.

Diese Unterscheidung ist für andere Teams entscheidend. Eine ausgereifte Testsuite und klar definiertes Verhalten können eine automatisierte Migration plausibel machen.

Ein unzureichend getestetes System bietet keine vergleichbare Referenzinstanz. Agenten können Code erzeugen, der kompiliert, während sich das Verhalten, auf das Nutzer angewiesen sind, unbemerkt verändert.

Entwicklungsteams benötigen außerdem dauerhafte Aufzeichnungen, die Entscheidungen der Agenten erklären. Eine durchsuchbare Wissensdatenbank kann Migrationsregeln, Review-Ergebnisse und Annahmen zu Verantwortlichkeiten über einzelne Kontextfenster hinaus bewahren.

Das Bun-Projekt setzte dafür Portierungsdokumente, Lifetime-Übersichten, die Commit-Historie und Tests ein. Diese Artefakte waren kein administratives Beiwerk.

Sie bildeten das System, das eine so schnelle Codegenerierung überhaupt erst überprüfbar machte.

Rust kann keine Sicherheit garantieren, wo Bun weiterhin Unsafe-Code verwendet

Die Neuentwicklung reduziert mehrere Risikoklassen, rechtfertigt es aber nicht, Bun automatisch als speichersicher zu betrachten.

Buns mechanische Übersetzung behielt Low-Level-Zeigeroperationen und die umfangreiche Interaktion mit C- und C++-Bibliotheken bei. Diese Bereiche erfordern häufig Rusts Schlüsselwort unsafe.

Ein Unsafe-Block erlaubt Operationen, die der Borrow Checker nicht validieren kann. Der Programmierer muss die erforderlichen Regeln manuell einhalten.

Das bedeutet nicht, dass jeder Unsafe-Block einen Fehler enthält. Große Rust-Systeme verwenden Unsafe-Code, um effiziente Abstraktionen zu implementieren und Betriebssysteme oder native Bibliotheken anzubinden.

Es bedeutet jedoch, dass Rusts wertvollste Garantien davon abhängen, wie diese Grenzen entworfen, dokumentiert und geprüft werden.

Sumner berichtete, dass sich zunächst etwa vier Prozent von Buns Rust-Code in Unsafe-Blöcken befanden. Er nannte ungefähr 27.000 Unsafe-Zeilen bei insgesamt rund 780.000 Zeilen Rust-Code.

Zudem bestanden seinen Angaben zufolge 78 Prozent dieser Blöcke aus nur einer Zeile. Viele verarbeiteten einen C++-Zeiger oder einen einzelnen Aufruf einer nativen Bibliothek.

Diese Einordnung ist relevant, doch die Länge eines Blocks belegt nicht dessen Korrektheit. Schon eine einzige unsichere Zeigerkonvertierung kann einen Lifetime-Fehler erzeugen, der sich auf sicheren Code an anderer Stelle auswirkt.

Ein öffentlich gemeldetes Problem mit der Speichersicherheit verdeutlichte diese Sorge am 14. Mai. Der Bericht zeigte, wie eine sichere Funktion die Lifetime eines Slice entfernte und dadurch eine Dangling Reference ermöglichte.

Miri, ein Interpreter zur Erkennung undefinierten Verhaltens in Rust-Programmen, meldete das Beispiel. Undefiniertes Verhalten bedeutet, dass die Sprache keine verlässlichen Vorgaben für das Ergebnis macht.

Buns automatisierter Mitwirkender reproduzierte das Problem und identifizierte eine vergleichbare Lifetime-Lücke. Die vorgeschlagene Korrektur kennzeichnete die betroffenen Funktionen als unsafe und dokumentierte ihre Lifetime-Anforderungen.

Die Reaktion zeigte, dass das Projekt einen konkreten Bericht schnell bearbeiten konnte. Sie zeigte zugleich, dass weder die Kompilierung noch die bestehende Testsuite jede ungültige Abstraktion verhindert hatten.

Diese Lücke stützt das stärkste skeptische Argument gegen die Neuentwicklung. Wenn automatisierte Tests Speicherfehler in Zig übersahen, können dieselben Tests nicht beweisen, dass ein großer Rust-Port korrekt und sicher ist.

Rust ergänzt die Durchsetzung durch den Compiler, doch in Unsafe-Abschnitten liegt die Verantwortung wieder bei den Entwicklern. Eine mechanische Übersetzung kann innerhalb dieser Abschnitte die ursprüngliche Zeigerdisziplin beibehalten.

Zig-Erfinder Andrew Kelley äußerte die schärfste öffentliche Kritik. In seiner Reaktion auf die Neuentwicklung argumentierte er, Buns Probleme seien auf Entwicklungspraktiken und angesammelte technische Schulden zurückzuführen, nicht auf ein Versagen von Zig.

Kelley bezweifelte außerdem, dass eine enorme Menge modellgenerierten Codes ausreichend von Menschen geprüft worden sei. Seine Kritik wurde stellenweise persönlich, was von der technischen Frage ablenkte.

Diese Frage bleibt berechtigt: Welches Maß an unabhängiger Prüfung sollte für Infrastruktur erforderlich sein, bevor Teams einer KI-generierten Neuentwicklung vertrauen?

Bun zufolge wurde jede Zeile von zwei separaten Claude-Instanzen überprüft. Eine Modellprüfung ist jedoch nicht mit unabhängigem menschlichem Urteilsvermögen gleichzusetzen.

Instanzen desselben Modells können dieselben blinden Flecken, Trainingsmuster und falschen Annahmen teilen. Getrennte Kontextfenster verringern Verankerungseffekte, schaffen aber keine wirklich unabhängige Expertise.

Automatisierte Reviewer entdeckten vor dem Merge mehrere plausible Fehler. Einer betraf einen asynchronen Schließvorgang, der eine Ressource zweimal freigegeben hätte.

Ein weiterer verarbeitete negative Zeitstempel falsch. Ein dritter verwendete eine eager ausgeführte Rust-Methode, die beim Parsen bestimmter CSS-Farbausdrücke eine Panic ausgelöst hätte.

Diese Beispiele zeigen, dass adversariales Review einen echten Beitrag leistete. Sie geben jedoch keinen Aufschluss darüber, wie viele Fehler sämtliche prüfenden Agenten gemeinsam übersahen.

Die Debatte sollte nicht auf die Entscheidung reduziert werden, KI-generierten Code entweder zu akzeptieren oder abzulehnen. Die sinnvollere Frage betrifft das Maß der Absicherung.

Teams vertrauen bereits auf Compiler, statische Analysewerkzeuge, Fuzzer, formale Modelle und automatisierte Testsysteme. Coding-Agenten können diese Sammlung ergänzen, ohne zur letzten Entscheidungsinstanz zu werden.

Prismas Position bietet einen praktikablen Mittelweg. Das Unternehmen setzte den Port für seine öffentliche Beta ein und meldete Verbesserungen in bekannten Fehlerszenarien.

Gleichzeitig erklärte Prisma, Unsafe-Code müsse auditiert und übersetzter Code überprüft werden. Es empfahl, nicht idiomatische Abschnitte in Teile zu refaktorieren, die Menschen verstehen können.

Bun hat eine ähnliche Zusage gemacht. Das ursprüngliche Ziel bestand darin, das Verhalten beizubehalten; anschließend sollte die Unsafe-Nutzung schrittweise reduziert und idiomatischeres Rust eingeführt werden.

Diese Reihenfolge ist vertretbar, verschiebt jedoch einen Teil des Sicherheitsgewinns in die Zukunft. Solange die Unsafe-Angriffsfläche nicht schrumpft, bleibt die Migration ein fortlaufendes Entwicklungsprogramm.

Das Argument reicht zudem über die Speichersicherheit hinaus. Eine Runtime kann durch fehlerhafte Modulauflösung, inkompatible APIs, Netzwerkverhalten, Leistungseinbußen oder subtile Unterschiede zwischen Betriebssystemen scheitern.

Rust verhindert keine logischen Fehler. Ebenso wenig beweist eine Testsuite mit einer Million Assertions das korrekte Verhalten für jedes existierende JavaScript-Paket.

Bun benötigt daher externe Workloads, unabhängige Audits, Fuzzing und langfristige Produktionseinsätze. Jede dieser Maßnahmen liefert Erkenntnisse, die interne Validierung allein nicht erbringen kann.

Die Bun-Neuentwicklung in Rust nach der Übernahme durch Anthropic sollte als vielversprechende Migration betrachtet werden, die weiterhin aktiv überprüft wird. Sie bereits als vollständigen Sicherheitserfolg oder als automatisiertes Scheitern zu bezeichnen, ginge über die verfügbaren Belege hinaus.

Drei Signale werden darüber entscheiden, ob Buns Neuentwicklung erfolgreich war

Die nächste Phase ist weniger spektakulär als der elftägige Port, wird aber darüber entscheiden, ob die Neuentwicklung zum Vorbild oder zur Warnung wird.

Das erste Signal ist das Verhalten von Bun 1.4 in gewöhnlichen Produktionsumgebungen. Bun v1.3.14 war die letzte Zig-Version, während v1.4 die Rust-Implementierung einführte.

Teams sollten nach einer breiteren Einführung Absturzberichte, Speicherverbrauch, Kompatibilitätsregressionen und Rollbacks beobachten. Eine erfolgreiche Version sollte Speicherfehler reduzieren, ohne eine neue Kategorie verhaltensbezogener Fehler zu schaffen.

Die frühen Deployments bei Claude Code und Prisma stärken Buns Argumentation. Sie decken jedoch nicht die gesamte Vielfalt an Paketkombinationen, Betriebssystemen, nativen Modulen und Workload-Mustern ab.

Eine breite Nutzung wird Codepfade offenlegen, die Buns interne Testsuite nie erreicht hat. Stabile Ergebnisse über mehrere Release-Zyklen hinweg wären aussagekräftiger als Benchmarks zum Marktstart.

Das zweite Signal ist Umfang und Gestaltung von Buns Unsafe-Rust-Oberfläche. Reine Zahlen benötigen Kontext, da Runtimes mit intensiver FFI-Nutzung Unsafe-Code nicht vollständig beseitigen können.

Entscheidender ist, ob unsichere Operationen hinter kleinen, dokumentierten Schnittstellen gekapselt werden. Jede Schnittstelle sollte die Annahmen zu Lifetime, Aliasing, Ownership und Thread-Sicherheit benennen, die Aufrufer einhalten müssen.

Unabhängige Audits würden diese Arbeit stärken. Öffentliche Miri-Befunde sowie Ergebnisse von Sanitizern und Fuzzing sollten ebenfalls sichtbar behoben und durch Regressionstests abgesichert werden.

Wenn die Unsafe-Nutzung zurückgeht, während Bun Leistung und Kompatibilität bewahrt, wird das Sicherheitsargument für die Neuentwicklung überzeugender. Wiederholte Lifetime-Fehler innerhalb sicherer Schnittstellen würden es dagegen schwächen.

Das dritte Signal ist, ob ein weiteres ausgereiftes Projekt Buns Migrationsmethode reproduzieren kann. Bun verfügte über eine ungewöhnlich günstige Ausgangslage: umfangreiche Tests, einen zentralen Architekten und einen Eigentümer mit Zugriff auf ein noch nicht veröffentlichtes Modell.

Eine zweite erfolgreiche Migration müsste mehr belegen als nur eine schnelle Codegenerierung. Sie sollte die menschliche Überprüfung, die Entdeckung von Fehlern, betriebliche Kontrollmechanismen und die Wartung nach der Veröffentlichung dokumentieren.

Sollten sich diese Ergebnisse wiederholen, könnten KI-gestützte Migrationen zwischen Programmiersprachen zu einer üblichen Option für Projekte werden, die bislang durch jahrelange Kosten einer Neuentwicklung ausgebremst werden.

Bleibt Bun dagegen ein Einzelfall, wäre die daraus zu ziehende Lehre enger gefasst. Die Leistung wäre weiterhin bedeutsam, würde jedoch mehr über Buns Testinfrastruktur aussagen als über die Softwareentwicklung im Allgemeinen.

Im größeren Wettbewerb geht es nicht um Rust gegen Zig. Es geht um maschinell erzeugte Geschwindigkeit gegen die Nachweise, die erforderlich sind, um grundlegender Software vertrauen zu können.

Bun hat diesen Wettbewerb aus dem Bereich der Spielzeugprojekte in eine Runtime mit mehr als 22 Millionen monatlichen Downloads verlagert. Anthropic integrierte das Ergebnis zudem in Claude Code, noch bevor die öffentliche Debatte abgeschlossen war.

Diese Entscheidung verschafft Bun wertvolles Feedback aus dem Produktiveinsatz. Sie verpflichtet Anthropic aber auch dazu, nachzuweisen, dass seine Coding-Agenten den von ihnen generierten Code dauerhaft warten können.

Entwickler sollten Release Notes, ungeklärte Sicherheitsberichte und unabhängige Ergebnisse aus Produktivumgebungen verfolgen, bevor sie risikoreiche Migrationen vornehmen. Außerdem sollten sie ihre eigenen Abhängigkeiten unter realistischen Lastbedingungen testen.

Die Neuentwicklung von Bun in Rust nach der Übernahme durch Anthropic hat bereits gezeigt, dass eine KI-gestützte Portierung eine bislang unüberwindbar scheinende Größengrenze überschreiten kann.

Offen bleibt, ob der Verifizierungsprozess mit dem Generierungsprozess Schritt halten kann. Entscheidend werden die Praxisergebnisse von Bun 1.4, Prüfungen des Unsafe-Codes und das nächste Großprojekt sein, das dieselbe Methode erprobt.