Rewriting Bun in Rust

Punti chiave

1. 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.
2. 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".
3. 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.
4. 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".
5. 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.
6. 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.
7. "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.
8. 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.
9. 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.
10. ~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).
11. 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.
12. 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".
13. 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).
14. 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.
15. 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.