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

## Veille

Resoconto tecnico di prim'ordine di **Jarred Sumner**, creatore di **Bun** (runtime JS/TS, >22M download/mese), sulla **riscrittura completa di Bun da Zig a Rust in 11 giorni** (3→14 maggio 2026) guidata da **Claude** — un caso di studio eccezionale di ingegneria del software assistita dall'IA **su scala industriale**. Motivazione: una classe ricorrente di bug (use-after-free, double-free, leak) derivante dal mix di memoria gestita da GC (JavaScriptCore) e memoria manuale (Zig); in **Rust sicuro**, questi bug diventano **errori di compilazione** con pulizia automatica (`Drop`/RAII) — "un ciclo di feedback migliore di una guida di stile". Rifiutando il dogma secondo cui "una riscrittura è sempre una cattiva idea" (un anno di blocco delle correzioni di bug per 3 ingegneri), Sumner sceglie un **porting meccanico** (preservare l'architettura, cambiamento minimo del comportamento) validato dalla **suite di test esistente, scritta in TypeScript e quindi indipendente dal linguaggio** (60.624 test, 1,39M asserzioni `expect()`, 0 test rimossi, 6 piattaforme). L'harness: **~50 workflow dinamici** in **Claude Code**, cicli *scrittura → 2+ revisori avversari → applicazione*, fino a **64 istanze Claude in parallelo** (4 worktree × 16), con **PORTING.md** + **LIFETIMES.tsv** generati in preparazione. Numeri: **6.502 commit** (picco 695/h, 58/min, ~1.300 righe/min), diff finale **+1.009.272 righe**, ~16.000 errori di compilazione trattati come una coda, **5,9 miliardi di token di input non in cache + 690M di output ≈ 165.000 $**. Leve metodologiche chiave: la **revisione avversaria** (un secondo Claude, contesto separato, vede solo il diff, incaricato di trovare perché è sbagliato — individua bug sottili che sono *semanticamente* diversi ma *sintatticamente* identici) e il principio **"correggere il processo che genera il codice, non il codice a mano".** Modello utilizzato: una pre-release di **Claude Fable 5** (classe Mythos). Dopo il merge: **11 round di revisione di sicurezza Claude Code**, fuzzing guidato dalla copertura 24/7 (100 miliardi di esecuzioni → ~15 PR), **4% di codice `unsafe`** (78% su una singola riga), **19** regressioni note corrette. In produzione: Claude Code v2.1.181, la prima release su Bun-in-Rust, **+10% di avvio più veloce su Linux**. Dichiarato in apertura: **Bun è stato acquisito da Anthropic nel dicembre 2025**.

## Titre Article

Rewriting Bun in Rust

## Date

2026-07-08

## URL

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

## Keywords

Bun, Jarred Sumner, riscrittura da Zig a Rust, porting meccanico, runtime JavaScript TypeScript, esbuild, acquisizione di Anthropic, Claude Fable 5, classe Mythos, Claude Code, workflow dinamici, harness engineering, 64 istanze Claude in parallelo, git worktree, revisione avversaria, revisione avversaria, finestre di contesto separate, 1 implementatore 2 revisori 1 correttore, ciclo scrittura-revisione-applicazione, correggere il processo non il codice, PORTING.md, LIFETIMES.tsv, Rust sicuro, Drop, RAII, use-after-free, double-free, memory leak, garbage collector, JavaScriptCore, gestione manuale della memoria, defer errdefer, guida di stile, TigerStyle, smart pointer, ~100 crate, dipendenze cicliche, 16000 errori di compilazione, coda di errori, smoke test, systemd-run cgroups, isolamento, suite di test TypeScript indipendente dal linguaggio, 60624 test, 1, 39M asserzioni expect, 0 test rimossi, 6 piattaforme, Buildkite CI, 6502 commit, 1009272 righe, 5, 9 miliardi di token di input, 690M token di output, 165000 dollari, 11 giorni, ReleaseSafe, Address Sanitizer, ASAN, Fuzzilli, fuzzing guidato dalla copertura, 100 miliardi di esecuzioni, 11 round di revisione di sicurezza, codice unsafe 4%, 19 regressioni, macro debug_assert, semanticamente diverso sintatticamente identico, Claude Code v2.1.181, 10% di avvio più veloce, LTO cross-language, binario 20% più piccolo, un ingegnere può fare molto di più, cimitero dei side project morti

## Authors

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

## Ton

**Profilo**: post tecnico di ingegneria in prima persona (blog ufficiale di Bun), formato lungo (~5000 parole), rivolto a ingegneri di sistemi/runtime e alla comunità dell'ingegneria del software assistita dall'IA. **Divulgazione anticipata** ("Bun è stato acquisito da Anthropic nel dicembre 2025; ho usato una pre-release di Claude Fable 5"), che disinnesca il conflitto di interessi senza nasconderlo. Tecnicità molto elevata (lifetime, `Drop` vs `defer`, dipendenze cicliche tra crate, timespec negativo, `unwrap_or` eager vs `unwrap_or_else` lazy) ma pedagogica: ogni decisione è motivata dal ragionamento "come lo farebbe un umano?"

**Stile**: onestà metodologica dichiarata — l'autore racconta i suoi **falsi avvii** (Claude che fa `git stash`/`reset` e collide tra le istanze; Claude che "stubba" le funzioni invece di correggerle; timeout di debug; disco saturato per IOPS insufficienti) tanto quanto i suoi successi. Rifiuto esplicito del prompt magico ("Riscrivi Bun in Rust. Non fare errori." non è *ciò che* ha fatto). Riconoscimento sincero dello strumento che sta lasciando ("Zig ha reso possibile Bun… gli sarò sempre grato"). Citazioni testuali degne di nota: *"L'esito predefinito per progetti dall'ambizione di Bun è unirsi al cimitero dei side project morti"*, *"Un ingegnere oggi può fare molto di più rispetto a un anno fa"*, *"Se ti serve un commento lungo un paragrafo per giustificare perché il workaround va bene, il codice è sbagliato — correggi il codice"*, *"Questo è il limite estremo di ciò che è possibile oggi"*. Ricco di visualizzazioni di dati (commit per ora, la corsa al verde per piattaforma, un replay di 11 giorni). Documentato con numeri di commit reali (attribuzione delle revisioni nell'oggetto del commit).

## Pense-betes

- **Idea chiave: le riscritture di linguaggio non sono più una decisione irreversibile.** Storicamente, cambiare il linguaggio di un progetto come Bun (535.496 righe di Zig) = ~1 anno per un piccolo team, con **un blocco di bugfix, sicurezza e feature** — quindi irrealistico, quindi "non lo si fa mai". L'IA agentica trasforma questo compromesso: *"E se passassi una settimana a testare se il nuovo modello di Anthropic può riscrivere Bun in Rust?"* Risultato: **11 giorni**.
- **L'argomento del "perché Rust" riguarda i cicli di feedback, non i gusti.** La classe di bug dominante (use-after-free, double-free, chiamate `free` mancate sui percorsi di errore) deriva dal mix di **memoria GC (JavaScriptCore) × memoria manuale (Zig)** — un caso per cui pochi linguaggi sono progettati. In **Rust sicuro**, questi diventano **errori di compilazione** + pulizia automatica (`Drop`, RAII). "Gli errori del compilatore sono un ciclo di feedback migliore di una guida di stile." Zig privilegia il `defer` esplicito (nessun flusso di controllo nascosto); l'alternativa — smart pointer fatti in casa — offriva "un'ergonomia peggiore di Rust, senza le garanzie".
- **Il vincolo che rende fattibile la scommessa: una suite di test indipendente dal linguaggio.** I test di Bun sono **scritti in TypeScript** → non dipendono dal linguaggio di implementazione. Il porting punta a un **cambiamento minimo del comportamento**, validato da questa suite (60.624 test, 1,39M chiamate `expect()`, **0 test rimossi o saltati**, verificati a mano). Questa è la rete di sicurezza che consente di fare merge di 1M di righe generate da un LLM.
- **Porting meccanico > riprogettazione.** Scelta esplicita: preservare l'architettura Zig, minimizzare i cambiamenti, lasciare il Rust **idiomatico** per *dopo* la release v1.4. "Incrementale o tutto insieme?" → tutto insieme (come per il suo porting originale di esbuild da Go a Zig, senza LLM). Tutto il resto "è solo tattica".
- **L'harness: ~50 workflow dinamici in Claude Code, in loop per 11 giorni.** Pseudocodice come dichiarato: `while (task = todo.pop()) { result = task(); feedback = await [review(result), review(result)]; apply(feedback) }`. Workflow dedicati: generare la guida di porting → portare meccanicamente ogni file `.zig` a `.rs` → correggere gli errori di compilazione per crate → far passare i sottocomandi (`bun test`, `bun build`) → far passare l'intera suite → refactoring/pulizia.
- **La revisione avversaria, il nucleo dell'affidabilità.** Un **secondo Claude, in un contesto separato, che vede SOLO il diff** (nessun ragionamento dell'implementatore), incaricato di "trovare perché è sbagliato". Rapporto di **1 implementatore / 2+ revisori avversari / 1 correttore**; l'implementatore non rivede, il revisore non implementa (come per gli umani, chi scrive il codice è portato a favorire il merge). Individua bug **sintatticamente identici ma semanticamente diversi**: un `Box` rilasciato prima di un `uv_close` asincrono (UAF + double-free); un timespec negativo tramite `trunc` invece di `floor`; un `unwrap_or` **eager** che va in panic dove un `unwrap_or_else` **lazy** non lo avrebbe fatto.
- **"Correggere il processo che genera il codice, non il codice a mano."** Principio guida: quando appare un bug o un anti-pattern, viene modificato il **workflow/prompt**, non il file. Es.: quando Claude aggiunge lunghi commenti per giustificare workaround, viene aggiunta una regola per i revisori → *"Se ti serve un commento lungo un paragrafo per giustificare perché il workaround va bene, il codice è sbagliato — correggi il codice."* Una modifica al prompt, qualche ora, il comportamento scompare.
- **Preparazione (riduzione del rischio) prima di scrivere una sola riga.** ~3 ore di discussione con Claude → **PORTING.md** (mappatura di pattern/tipi Zig→Rust). Poi un workflow che analizza **il lifetime di ogni campo di struct** (lettura + tracciamento del flusso di controllo, 2 revisori avversari), serializzato in **LIFETIMES.tsv** per le altre istanze Claude. Poi una **prova su 3 file** prima del lancio sui 1.448.
- **Il parallelismo e i suoi falsi avvii.** Lanciando tutti i 1.448 file in una volta → le istanze Claude entrano in collisione (`git stash`/`stash pop`/`reset --hard`). Correzione: **vietare qualsiasi operazione git che non faccia commit di un file specifico**, niente `cargo`, niente comandi lenti. Poi **4 shard / 4 worktree × 16 Claude** = **~64 istanze Claude** simultanee. Picco: **1.300 righe/min**, **695 commit/h**, 58 commit/min. Un `grep` lento ha bloccato il disco per IOPS insufficienti sull'istanza EC2.
- **~16.000 errori di compilazione trattati come una coda.** Suddivisi in **~100 crate** (compilazione più veloce) → rivela **dipendenze cicliche** (la codebase Zig era un'unica unità di compilazione) → workflow di classificazione seguiti da workflow di refactoring. `cargo check` scrive gli errori in un file raggruppato per crate → distribuiti tra 64 istanze Claude. Isolamento rafforzato tramite **systemd-run (cgroups)** per i test di memory-leak/stress (10k processi, gigabyte di riempimento del disco, socket TCP saturati).
- **La strada verso il verde (Buildkite CI, 6 piattaforme).** Da 972 file di test falliti a 23 in 2 giorni; Linux completamente verde ~1 giorno prima di Windows; build #54202 = **6/6 piattaforme verdi** → merge. Merge ≠ rilascio: fiducia sufficiente per il commit, non ancora per lo ship.
- **Costo, quantificato e assunto.** Pre-merge: **5,9 miliardi di token di input non in cache + 690M di output + 72 miliardi di letture cache ≈ 165.000 $** ai prezzi API. Alternativa umana realistica: **3 ingegneri, ~1 anno**, durante il quale "non avremmo migliorato la compatibilità con Node.js, corretto bug/vulnerabilità o rilasciato feature" — quindi **mai fatto**. "L'alternativa realistica era non fare nulla e continuare a correggere i bug per sempre".
- **Dopo il merge, il lavoro continua.** **11 round** di revisione **Claude Code Security**; **fuzzing guidato dalla copertura 24/7** di tutti i parser (JS/TS/JSX/CSS/JSON5/TOML/YAML/Markdown/INI/Bun Shell/semver/.patch), **100 miliardi di esecuzioni → ~15 PR** (il fuzzer invia il repro a Claude, che invia la PR, seguita da revisione umana). **~4% di codice `unsafe`** (~13.000 blocchi `unsafe` / ~780.000 righe), di cui **78% su una singola riga** (un puntatore proveniente da C++ o da una chiamata C) — atteso in calo verso un Rust idiomatico. **19** regressioni note, tutte corrette (ad es., la macro `debug_assert!` rimossa nelle build di release → HMR rotto).
- **Il modello e la produzione.** Una pre-release di **Claude Fable 5** ("un modello di classe Mythos"); i workflow dinamici di Claude Code hanno sostenuto **64 istanze Claude per 11 giorni** ("altrimenti avrei dovuto scrivere il mio harness"). Prima release su Bun-in-Rust: **Claude Code v2.1.181**, **+10% di avvio più veloce su Linux**, cambiamenti minimi visibili all'utente → prova della maturità in produzione.
- **Correlati**: revisione del codice basata su agenti / verifica avversaria e consenso (Monperrus, "The End of Code Review", serie ADLC in stile Kent Beck "prosecution not code review" / "tests are the spec"); **Loop/Harness Engineering** (Lushbinary, Osmani, OpenAI Codex agent-first, la tecnica Ralph, git worktree); skill Claude Code & workflow dinamici; Zig già presente nel corpus (ZML/LLMD, sovranità del silicio); FinOps dei token / costo per risultato.

## RésuméDe400mots

Jarred Sumner, creatore di **Bun** (runtime JS/TS, >22M download/mese, acquisito da **Anthropic** nel dicembre 2025), racconta la **riscrittura completa di Bun da Zig a Rust in 11 giorni** (3→14 maggio 2026), guidata da Claude. La motivazione è una classe ricorrente di bug — use-after-free, double-free, leak — derivante dal mix di memoria gestita da GC (JavaScriptCore) e memoria manuale (Zig). In **Rust sicuro**, questi bug diventano **errori di compilazione** con pulizia automatica (`Drop`/RAII): "un ciclo di feedback migliore di una guida di stile".

Contro il dogma secondo cui "una riscrittura è sempre una cattiva idea" (un anno di blocco delle correzioni di bug per 3 ingegneri su 535.496 righe di Zig), Sumner opta per un **porting meccanico**: preservare l'architettura, minimizzare i cambiamenti di comportamento, validare rispetto alla **suite di test esistente — scritta in TypeScript, e quindi indipendente dal linguaggio** (60.624 test, 1,39M asserzioni, 0 test rimossi, 6 piattaforme).

L'harness: **~50 workflow dinamici** in **Claude Code**, in cicli *scrittura → revisione → applicazione*, in esecuzione continua. Il blocco costitutivo dell'affidabilità è la **revisione avversaria**: un secondo Claude, in un **contesto separato che vede solo il diff**, incaricato di "trovare perché è sbagliato". Rapporto di **1 implementatore / 2+ revisori / 1 correttore**; l'implementatore non rivede il proprio lavoro. Individua bug sottili sintatticamente identici ma semanticamente diversi (un `Box` rilasciato prima di un `uv_close` asincrono; un `unwrap_or` eager che va in panic). Principio cardine: **"correggere il processo che genera il codice, non il codice a mano"** — quando appare un anti-pattern, il prompt/workflow viene modificato.

Preparazione accurata: **PORTING.md** (mappatura Zig→Rust) e **LIFETIMES.tsv** (lifetime di ogni campo di struct), una prova su 3 file prima dei 1.448. Poi **4 worktree × 16 = ~64 istanze Claude** in parallelo, dopo aver vietato tutte le operazioni git non atomiche. Picco: **1.300 righe/min**, **695 commit/h**; **6.502 commit**, diff **+1.009.272 righe**, ~16.000 errori di compilazione trattati come una coda (suddivisi in ~100 crate, risolvendo le dipendenze cicliche).

Costo dichiarato: **5,9 miliardi di token di input non in cache + 690M di output ≈ 165.000 $**, contro ~3 ingegneri per un anno — "cosa che non avremmo mai fatto". Modello: una pre-release di **Claude Fable 5** (classe Mythos). Dopo il merge: **11 round** di revisione di sicurezza Claude Code, fuzzing 24/7 (100 miliardi di esecuzioni → ~15 PR), **4% di codice `unsafe`**, **19 regressioni** corrette. Prima release: Claude Code v2.1.181, **+10% di avvio più veloce su Linux**. "Questo è il limite estremo di ciò che è possibile oggi".

## 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/it/fiches/sumner-bun-rewrite-rust-claude-2026-07-08/