# sumner-bun-rewrite-rust-claude-2026-07-08

## Veille

Erstklassiger technischer Bericht von **Jarred Sumner**, dem Schöpfer von **Bun** (JS/TS-Runtime, >22 Mio. Downloads/Monat), über die **vollständige Neuschreibung von Bun von Zig nach Rust in 11 Tagen** (3.–14. Mai 2026), angetrieben durch **Claude** — eine außergewöhnliche Fallstudie zu KI-gestützter Softwareentwicklung **im industriellen Maßstab**. Motivation: eine wiederkehrende Klasse von Fehlern (Use-after-free, Double-free, Speicherlecks), die aus der Vermischung von GC-verwaltetem Speicher (JavaScriptCore) und manuellem Speicher (Zig) entsteht; in **sicherem Rust** werden diese Fehler zu **Kompilierfehlern** mit automatischer Bereinigung (`Drop`/RAII) — "eine bessere Feedback-Schleife als ein Style Guide." Unter Zurückweisung des Dogmas, dass "eine Neuschreibung immer eine schlechte Idee ist" (ein Jahr Bugfix-Stillstand für 3 Ingenieure), entscheidet sich Sumner für einen **mechanischen Port** (Architektur beibehalten, minimale Verhaltensänderung), validiert durch die **bestehende Testsuite, geschrieben in TypeScript und daher sprachunabhängig** (60.624 Tests, 1,39 Mio. `expect()`-Assertions, 0 entfernte Tests, 6 Plattformen). Das Setup: **~50 dynamische Workflows** in **Claude Code**, Schleifen aus *Schreiben → 2+ adversarielle Reviewer → Anwenden*, bis zu **64 parallele Claude-Instanzen** (4 Worktrees × 16), mit vorbereitend generierten **PORTING.md** + **LIFETIMES.tsv**. Zahlen: **6.502 Commits** (Spitzenwert 695/h, 58/min, ~1.300 Zeilen/min), finaler Diff **+1.009.272 Zeilen**, ~16.000 Kompilierfehler als Warteschlange behandelt, **5,9 Mrd. ungecachte Input-Tokens + 690 Mio. Output ≈ 165.000 US-Dollar**. Zentrale methodische Hebel: **adversarielles Review** (ein zweiter Claude, separater Kontext, sieht nur den Diff, mit der Aufgabe herauszufinden, warum es falsch ist — erkennt subtile Fehler, die *semantisch* verschieden, aber *syntaktisch* identisch sind) und das Prinzip **"den Prozess reparieren, der den Code erzeugt, nicht den Code von Hand."** Verwendetes Modell: eine Vorabversion von **Claude Fable 5** (Mythos-Klasse). Seit dem Merge: **11 Runden** Sicherheitsreview durch Claude Code, 24/7 coverage-gesteuertes Fuzzing (100 Mrd. Ausführungen → ~15 PRs), **4 % `unsafe`-Code** (78 % davon auf einer einzigen Zeile), **19** behobene bekannte Regressionen. In Produktion: Claude Code v2.1.181, das erste Release auf Bun-in-Rust, **10 % schnellerer Start unter Linux**. Vorab offengelegt: **Bun wurde im Dezember 2025 von Anthropic übernommen**.

## Titre Article

Rewriting Bun in Rust

## Date

2026-07-08

## URL

https://bun.com/blog/bun-in-rust

## Keywords

Bun, Jarred Sumner, Zig-zu-Rust-Neuschreibung, mechanischer Port, JavaScript-TypeScript-Runtime, esbuild, Anthropic-Übernahme, Claude Fable 5, Mythos-Klasse, Claude Code, dynamische Workflows, Harness Engineering, 64 parallele Claude-Instanzen, Git-Worktrees, adversarielles Review, adversarielles Review, getrennte Kontextfenster, 1 Implementierer 2 Reviewer 1 Fixer, Schreiben-Review-Anwenden-Schleife, den Prozess reparieren, nicht den Code, PORTING.md, LIFETIMES.tsv, sicheres Rust, Drop, RAII, Use-after-free, Double-free, Speicherleck, Garbage Collector, JavaScriptCore, manuelle Speicherverwaltung, defer errdefer, Style Guide, TigerStyle, Smart Pointer, ~100 Crates, zyklische Abhängigkeiten, 16000 Kompilierfehler, Fehler-Warteschlange, Smoke-Tests, systemd-run cgroups, Isolation, sprachunabhängige TypeScript-Testsuite, 60624 Tests, 1, 39 Mio. expect-Assertions, 0 entfernte Tests, 6 Plattformen, Buildkite CI, 6502 Commits, 1009272 Zeilen, 5, 9 Milliarden Input-Tokens, 690 Mio. Output-Tokens, 165000 Dollar, 11 Tage, ReleaseSafe, Address Sanitizer, ASAN, Fuzzilli, coverage-gesteuertes Fuzzing, 100 Milliarden Ausführungen, 11 Runden Sicherheitsreview, unsafe-Code 4%, 19 Regressionen, debug_assert-Makro, semantisch verschieden syntaktisch identisch, Claude Code v2.1.181, 10% schnellerer Start, sprachübergreifendes LTO, Binärgröße 20% kleiner, ein Ingenieur kann heute viel mehr leisten, Friedhof toter Nebenprojekte

## Authors

Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)

## Ton

**Profil**: technischer Ingenieursbeitrag in der Ich-Perspektive (offizieller Bun-Blog), Langform (~5000 Wörter), gerichtet an Systems-/Runtime-Ingenieure und die Community für KI-gestützte Softwareentwicklung. **Vorab-Offenlegung** ("Bun wurde im Dezember 2025 von Anthropic übernommen; ich habe eine Vorabversion von Claude Fable 5 verwendet"), die den Interessenkonflikt entschärft, ohne ihn zu verbergen. Sehr hohe Technizität (Lifetimes, `Drop` vs. `defer`, zyklische Crate-Abhängigkeiten, negativer Timespec, eifriges `unwrap_or` vs. träges `unwrap_or_else`), aber pädagogisch: jede Entscheidung wird mit der Überlegung "wie würde ein Mensch das machen?" begründet.

**Stil**: bekennende methodische Ehrlichkeit — der Autor berichtet ebenso von seinen **Fehlstarts** (Claude, das `git stash`/`reset` ausführt und zwischen Instanzen kollidiert; Claude, das Funktionen "stubbt" statt sie zu reparieren; Debug-Timeouts; durch unzureichende IOPS gesättigte Festplatte) wie von seinen Erfolgen. Explizite Ablehnung des Zauber-Prompts ("Rewrite Bun in Rust. Don't make any mistakes." ist *nicht*, was er getan hat). Aufrichtige Anerkennung des Werkzeugs, das er hinter sich lässt ("Zig hat Bun möglich gemacht… ich werde immer dankbar sein"). Bemerkenswerte wörtliche Zitate: *"The default outcome for ambitiously-scoped projects like Bun is joining the graveyard of dead side projects"*, *"One engineer can do a lot more today than a year ago"*, *"If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code"*, *"This is the bleeding edge of what's possible today"*. Reich an Datenvisualisierungen (Commits pro Stunde, das Rennen zu Grün nach Plattform, ein 11-Tage-Replay). Belegt mit echten Commit-Zahlen (Review-Zuordnung im Commit-Betreff).

## Pense-betes

- **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**.
- **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."
- **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.
- **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."
- **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.
- **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.
- **"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.
- **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.
- **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.
- **~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).
- **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.
- **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."
- **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).
- **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.
- **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.

## RésuméDe400mots

Jarred Sumner, Schöpfer von **Bun** (JS/TS-Runtime, >22 Mio. Downloads/Monat, im Dezember 2025 von **Anthropic** übernommen), berichtet über die **vollständige Neuschreibung von Bun von Zig nach Rust in 11 Tagen** (3.–14. Mai 2026), angetrieben durch Claude. Die Motivation ist eine wiederkehrende Klasse von Fehlern — Use-after-free, Double-free, Speicherlecks —, die aus der Vermischung von GC-verwaltetem Speicher (JavaScriptCore) und manuellem Speicher (Zig) entsteht. In **sicherem Rust** werden diese Fehler zu **Kompilierfehlern** mit automatischer Bereinigung (`Drop`/RAII): "eine bessere Feedback-Schleife als ein Style Guide."

Entgegen dem Dogma, dass "eine Neuschreibung immer eine schlechte Idee ist" (ein Jahr Bugfix-Stillstand für 3 Ingenieure bei 535.496 Zeilen Zig), entscheidet sich Sumner für einen **mechanischen Port**: Architektur beibehalten, Verhaltensänderungen minimieren, validiert anhand der **bestehenden Testsuite — geschrieben in TypeScript und daher sprachunabhängig** (60.624 Tests, 1,39 Mio. Assertions, 0 entfernte Tests, 6 Plattformen).

Das Setup: **~50 dynamische Workflows** in **Claude Code**, in Schleifen aus *Schreiben → Review → Anwenden*, durchgehend laufend. Der Baustein für Zuverlässigkeit ist das **adversarielle Review**: ein zweiter Claude, in einem **separaten Kontext, der nur den Diff sieht**, mit der Aufgabe, "herauszufinden, warum es falsch ist." Verhältnis von **1 Implementierer / 2+ Reviewer / 1 Fixer**; der Implementierer prüft nicht seine eigene Arbeit. So werden subtile Fehler erkannt, die syntaktisch identisch, aber semantisch verschieden sind (eine `Box`, die vor einem asynchronen `uv_close` freigegeben wird; ein eifriges `unwrap_or`, das panikt, wo ein träges `unwrap_or_else` es nicht getan hätte). Leitprinzip: **"den Prozess reparieren, der den Code erzeugt, nicht den Code von Hand"** — sobald ein Anti-Pattern auftritt, wird der Prompt/Workflow bearbeitet.

Sorgfältige Vorbereitung: **PORTING.md** (Zig→Rust-Mapping) und **LIFETIMES.tsv** (Lebensdauer jedes Struct-Felds), ein Testlauf mit 3 Dateien vor den 1.448. Dann **4 Worktrees × 16 = ~64 parallele Claude-Instanzen**, nach dem Verbot aller nicht-atomaren Git-Operationen. Spitzenwert: **1.300 Zeilen/min**, **695 Commits/h**; **6.502 Commits**, Diff **+1.009.272 Zeilen**, ~16.000 Kompilierfehler als Warteschlange behandelt (aufgeteilt in ~100 Crates, mit Auflösung zyklischer Abhängigkeiten).

Offengelegte Kosten: **5,9 Mrd. ungecachte Input-Tokens + 690 Mio. Output ≈ 165.000 US-Dollar**, gegenüber ~3 Ingenieuren für ein Jahr — "was wir nie getan hätten." Modell: eine Vorabversion von **Claude Fable 5** (Mythos-Klasse). Seit dem Merge: **11 Runden** Sicherheitsreview durch Claude Code, 24/7-Fuzzing (100 Mrd. Ausführungen → ~15 PRs), **4 % `unsafe`-Code**, **19 behobene Regressionen**. Erstes Release: Claude Code v2.1.181, **10 % schnellerer Start unter Linux**, minimale sichtbare Änderungen für Nutzer → Beleg für Produktionsreife. "Das ist die Speerspitze dessen, was heute möglich ist."

## GrapheDeConnaissance

- Jarred Sumner —a_créé→ Bun (TECHNOLOGIE, 0.98)
- Bun —fait_partie_de→ Anthropic (ORGANISATION, 0.95)
- Jarred Sumner —travaille_chez→ Anthropic (ORGANISATION, 0.95)
- Jarred Sumner —utilise→ Claude Fable 5 (TECHNOLOGIE, 0.95)
- Bun —utilise→ Rust (TECHNOLOGIE, 0.97)
- Rust —remplace→ Zig (TECHNOLOGIE, 0.9)
- Rust —réduit→ use-after-free, double-free et fuites mémoire (erreurs de compilation en safe Rust) (AFFIRMATION, 0.9)
- Claude Fable 5 —permet→ réécriture mécanique de Bun de Zig vers Rust en 11 jours (AFFIRMATION, 0.9)
- réécriture de Bun en Rust —utilise→ dynamic workflows (METHODOLOGIE, 0.95)
- dynamic workflows —utilise→ revue adversariale (METHODOLOGIE, 0.92)
- revue adversariale —réduit→ régressions du code généré par LLM (CONCEPT, 0.88)
- Claude Code —permet→ ~64 Claude en parallèle pendant 11 jours (4 worktrees × 16) (AFFIRMATION, 0.9)
- réécriture de Bun en Rust —utilise→ suite de tests TypeScript indépendante du langage (CONCEPT, 0.92)
- Jarred Sumner —mesure→ ~165 000 $ (5,9 Md tokens d'entrée non cachés, 690 M en sortie) pour la réécriture (MESURE, 0.9)
- Jarred Sumner —recommande→ corriger le processus qui génère le code plutôt que le code à la main (AFFIRMATION, 0.9)
- Bun —utilise→ JavaScriptCore (TECHNOLOGIE, 0.9)
- Claude Code —utilise→ Bun (TECHNOLOGIE, 0.9)
- Bun (réécrit en Rust) —améliore→ démarrage de Claude Code de ~10 % sur Linux (MESURE, 0.85)
- coverage-guided fuzzing —résout→ bugs de parsers de Bun (100 Md exécutions → ~15 PRs) (AFFIRMATION, 0.85)
- Jarred Sumner —affirme_que→ one engineer can do a lot more today than a year ago (CITATION, 0.9)

---
Canonical: https://www.thekb.eu/de/fiches/sumner-bun-rewrite-rust-claude-2026-07-08/