Rewriting Bun in Rust

Kernpunkte

1. Kerngedanke: Sprach-Neuschreibungen sind keine Einbahnstraßen-Entscheidung mehr. Historisch bedeutete ein Sprachwechsel bei einem Projekt wie Bun (535.496 Zeilen Zig) ~1 Jahr für ein kleines Team, mit Stillstand bei Bugfixes, Sicherheit und Features — daher unrealistisch, daher "macht man es nie." Agentische KI verändert diesen Trade-off: "Was, wenn ich eine Woche damit verbringe zu testen, ob Anthropics neues Modell Bun nach Rust umschreiben kann?" Ergebnis: 11 Tage.
2. Das Argument "warum Rust" betrifft Feedback-Schleifen, nicht Geschmack. Die dominante Fehlerklasse (Use-after-free, Double-free, verpasste free-Aufrufe auf Fehlerpfaden) entsteht aus der Vermischung von GC-Speicher (JavaScriptCore) × manuellem Speicher (Zig) — ein Fall, für den nur wenige Sprachen ausgelegt sind. In sicherem Rust werden daraus Kompilierfehler + automatische Bereinigung (Drop, RAII). "Compilerfehler sind eine bessere Feedback-Schleife als ein Style Guide." Zig bevorzugt explizites defer (kein versteckter Kontrollfluss); die Alternative — selbstgebaute Smart Pointer — bot "schlechtere Ergonomie als Rust, ohne dessen Garantien."
3. Die Bedingung, die den Wetteinsatz machbar macht: eine sprachunabhängige Testsuite. Bun-Tests sind in TypeScript geschrieben → unabhängig von der Implementierungssprache. Der Port zielt auf minimale Verhaltensänderung, validiert durch diese Suite (60.624 Tests, 1,39 Mio. expect()-Aufrufe, 0 entfernte oder übersprungene Tests, von Hand geprüft). Das ist das Sicherheitsnetz, das erlaubt, 1 Mio. von einem LLM generierte Zeilen zu mergen.
4. Mechanischer Port > Neugestaltung. Explizite Entscheidung: Zig-Architektur beibehalten, Änderungen minimieren, idiomatisches Rust für nach dem v1.4-Release lassen. "Inkrementell oder alles auf einmal?" → alles auf einmal (wie beim ursprünglichen esbuild-Port von Go nach Zig, ohne LLM). Alles andere "ist nur Taktik."
5. Das Setup: ~50 dynamische Workflows in Claude Code, 11 Tage in Schleife. Pseudocode wie beschrieben: while (task = todo.pop()) { result = task(); feedback = await [review(result), review(result)]; apply(feedback) }. Dedizierte Workflows: den Porting-Guide erzeugen → jede .zig-Datei mechanisch nach .rs portieren → Kompilierfehler pro Crate beheben → die Subcommands zum Laufen bringen (bun test, bun build) → die gesamte Suite grün bekommen → Refactorings/Aufräumarbeiten.
6. Adversarielles Review, der Kern der Zuverlässigkeit. Ein zweiter Claude, in separatem Kontext, der NUR den Diff sieht (nichts von der Denkweise des Implementierers), mit der Aufgabe, "herauszufinden, warum es falsch ist." Verhältnis von 1 Implementierer / 2+ adversarielle Reviewer / 1 Fixer; der Implementierer reviewt nicht, der Reviewer implementiert nicht (wie bei Menschen ist die Person, die den Code schreibt, zum Mergen voreingenommen). Erkennt Fehler, die syntaktisch identisch, aber semantisch verschieden sind: eine Box, die vor einem asynchronen uv_close freigegeben wird (UAF + Double-free); ein negativer Timespec durch trunc statt floor; ein eifriges unwrap_or, das panikt, wo ein träges unwrap_or_else es nicht getan hätte.
7. "Den Prozess reparieren, der den Code erzeugt, nicht den Code von Hand.". Leitprinzip: Sobald ein Bug oder ein Anti-Pattern auftritt, wird der Workflow/Prompt bearbeitet, nicht die Datei. Beispiel: Wenn Claude lange Kommentare hinzufügt, um Workarounds zu rechtfertigen, wird eine Regel für Reviewer ergänzt → "Wenn du einen absatzlangen Kommentar brauchst, um zu rechtfertigen, warum der Workaround in Ordnung ist, ist der Code falsch — repariere den Code." Eine Prompt-Änderung, wenige Stunden, das Verhalten verschwindet.
8. Vorbereitung (Risikominimierung), bevor auch nur eine Zeile geschrieben wird. ~3 Stunden Diskussion mit Claude → PORTING.md (Zig→Rust-Muster-/Typ-Mapping). Dann ein Workflow, der die Lebensdauer jedes Struct-Felds analysiert (Lesen + Kontrollfluss-Tracing, 2 adversarielle Reviewer), serialisiert in LIFETIMES.tsv für die anderen Claude-Instanzen. Dann ein Testlauf mit 3 Dateien, bevor es mit den 1.448 losgeht.
9. Parallelität und ihre Fehlstarts. Start aller 1.448 Dateien auf einmal → die Claude-Instanzen kollidieren (git stash/stash pop/reset --hard). Fix: Verbot jeder Git-Operation, die nicht eine bestimmte Datei committet, kein cargo, keine langsamen Befehle. Dann 4 Shards / 4 Worktrees × 16 Claude = ~64 gleichzeitige Claude-Instanzen. Spitzenwert: 1.300 Zeilen/min, 695 Commits/h, 58 Commits/min. Ein langsamer grep-Befehl blockierte die Platte aufgrund unzureichender IOPS auf der EC2-Instanz.
10. ~16.000 Kompilierfehler als Warteschlange behandelt. Aufteilung in ~100 Crates (schnellere Kompilierung) → offenbart zyklische Abhängigkeiten (die Zig-Codebasis war eine einzige Kompilationseinheit) → Klassifizierungs-Workflows gefolgt von Refactoring-Workflows. cargo check schreibt Fehler in eine nach Crate gruppierte Datei → verteilt auf 64 Claude-Instanzen. Isolation verstärkt durch systemd-run (cgroups) für Speicherleck-/Stresstests (10.000 Prozesse, Gigabytes an Festplattenauslastung, gesättigte TCP-Sockets).
11. Der Weg zu Grün (Buildkite CI, 6 Plattformen). Von 972 fehlschlagenden Testdateien auf 23 in 2 Tagen; Linux vollständig grün ~1 Tag vor Windows; Build #54202 = 6/6 Plattformen grün → Merge. Mergen ≠ Ausliefern: genug Vertrauen zum Committen, noch nicht zum Ausliefern.
12. Kosten, quantifiziert und offengelegt. Vor dem Merge: 5,9 Mrd. ungecachte Input-Tokens + 690 Mio. Output + 72 Mrd. Cache-Reads ≈ 165.000 US-Dollar zu API-Preisen. Realistische menschliche Alternative: 3 Ingenieure, ~1 Jahr, in dem "wir die Node.js-Kompatibilität nicht verbessert, Bugs/Sicherheitslücken nicht behoben und keine Features ausgeliefert hätten" — daher nie getan. "Die realistische Alternative war, nichts zu tun und die Bugs für immer weiter zu beheben."
13. Nach dem Merge geht die Arbeit weiter. 11 Runden Review durch Claude Code Security; 24/7 coverage-gesteuertes Fuzzing aller Parser (JS/TS/JSX/CSS/JSON5/TOML/YAML/Markdown/INI/Bun Shell/Semver/.patch), 100 Mrd. Ausführungen → ~15 PRs (der Fuzzer schickt die Reproduktion an Claude, das den PR einreicht, gefolgt von menschlichem Review). ~4 % unsafe-Code (~13.000 unsafe-Blöcke / ~780.000 Zeilen), davon 78 % auf einer einzigen Zeile (ein Pointer aus C++ oder einem C-Aufruf) — erwartungsgemäß rückläufig in Richtung idiomatisches Rust. 19 bekannte Regressionen, alle behoben (z. B. das im Release-Build entfernte Makro debug_assert! → defektes HMR).
14. Das Modell und die Produktion. Eine Vorabversion von Claude Fable 5 ("ein Modell der Mythos-Klasse"); die dynamischen Workflows von Claude Code hielten 64 Claude-Instanzen 11 Tage lang aufrecht ("sonst hätte ich mein eigenes Harness schreiben müssen"). Erstes Release auf Bun-in-Rust: Claude Code v2.1.181, 10 % schnellerer Start unter Linux, minimale für Nutzer sichtbare Änderungen → Beleg für Produktionsreife.
15. Verwandtes. agentenbasiertes Code-Review / adversarielle Verifikation und Konsens (Monperruts "The End of Code Review," Kent-Beck-artige ADLC-Serie "prosecution not code review" / "tests are the spec"); Loop/Harness Engineering (Lushbinary, Osmani, OpenAI Codex Agent-first, die Ralph-Technik, Git-Worktrees); Claude Code Skills & dynamische Workflows; Zig bereits im Korpus (ZML/LLMD, silizium-basierte Souveränität); Token-FinOps / Kosten pro Ergebnis.