Bun skrevs om från Zig till Rust på elva dagar

Bun, JavaScript-runtimen som konkurrerar med Node.js och Deno, har fått hela sin kodbas översatt från Zig till Rust. Arbetet tog elva dagar i juli 2026 och gjordes till största delen av AI-agenter: 535 000 rader Zig blev över en miljon rader Rust, fördelat på 6 502 commits. Resultatet är fortfarande experimentellt och fungerar bara på Linux x64 med glibc. Den stabila versionen du laddar ner idag byggs fortfarande från Zig-koden.

Zig och JavaScriptCores skräpsamling drog åt olika håll

Bun byggdes ursprungligen i Zig omkring 2021. Valet var rimligt då. Zig gav C-liknande prestanda, explicit kontroll över minnet och en syntax som är betydligt lättare att läsa än C++. Projektet startade som en rad-för-rad-översättning av esbuilds transpiler från Go till Zig.

Problemet växte fram med tiden. Zig kräver att utvecklaren själv håller reda på allt minne, medan JavaScriptCore, motorn som kör själva JavaScript-koden, har en skräpsamlare som flyttar och frigör minne på egen hand. Två system som hanterar minne enligt helt olika logik, i samma process. Där de möttes uppstod buggarna.

De var inte teoretiska. I versioner till och med 1.3.14 fanns bland annat en use-after-free i `node:zlib` när `.reset()` anropades mitt under en pågående asynkron `.write()`, en läcka i `tlsSocket.setSession()` på ungefär 6,5 kilobyte per anrop eftersom `SSL_SESSION_free` aldrig kördes och `fs.watch()`-lyssnare som aldrig städades bort efter `.close()` på grund av en refcount som räknade fel åt andra hållet. Sådant här är svårt att hitta med tester och lätt att missa i granskning.

Rust löser inte magiskt allt men kompilatorn tvingar fram livstidsgarantier som Zig lämnar åt människan. Ungefär 27 000 rader av den nya koden ligger inom `unsafe`-block, av runt 780 000 totalt. Resten är kompilatorkontrollerad.

Anthropic köpte Bun och Zig-gemenskapen ville inte ha AI-kod

Den tekniska motiveringen är bara halva förklaringen. Bun förvärvades av Anthropic och därefter planerades betydande AI-genererade bidrag till kodbasen. Två saker talade emot Zig i det läget.

Det första är kulturellt. Zig-gemenskapen har varit uttalat skeptisk till AI-driven utveckling. Det andra är rent praktiskt: språkmodeller är bara så bra som sin träningsdata och det finns oerhört mycket mer publik Rust-kod än Zig-kod att lära sig av. En modell som ska skriva hundratusentals rader systemkod presterar helt enkelt bättre i Rust.

64 Claude-instanser körde parallellt för 165 000 dollar

Metoden kallades ”mekanisk port”. Arkitekturen behölls identisk, samma TypeScript-testsvit användes som facit och kompilatorfelen fungerade som arbetskö, så länge något inte byggde fanns nästa uppgift. Två oberoende AI-agenter granskade varje enhet och antog som utgångspunkt att koden var fel tills motsatsen bevisades.

Kostnaden är den siffra som väcker mest diskussion. 165 000 dollar för att skriva om en hel runtime är billigt jämfört med vad ett utvecklarteam hade kostat under den tid arbetet normalt tagit. Men jämförelsen haltar, eftersom hela arbetet vilade på en existerande testsvit som människor byggt upp under flera år. Projektet dokumenteras av Bun själva och de öppna pull requests som roboten lämnat går att bläddra igenom i repot.

Verifiering blev flaskhalsen, inte kodskrivandet

Agenterna producerade kod snabbare än någon människa kunde läsa den. Vanlig pull request-granskning, där en kollega ögnar igenom en diff och säger godkänt, kollapsar helt vid den volymen. Istället byggdes verifieringen om till något maskinerna kunde göra: fuzzing, kontinuerlig säkerhetstestning, adversariella granskningsagenter och en testsvit som fick avgöra om beteendet var likvärdigt.

Implementeringshastighet och verifieringshastighet blev två separata ingenjörsproblem. Det gäller i mindre skala också, vilket vi tidigare skrivit om i samband med när det är värt att skriva om kod som redan fungerar.

Rust har redan tagit över resten av JS-verktygskedjan

Bun är inte först. Titta på vad som byggt om sin kärna de senaste åren och ett mönster framträder direkt. SWC, transpileraren som Next.js använder. Rspack och Turbopack för bundling. Biome för linting och formattering. Oxc för parsing. Lightning CSS för CSS-bearbetning. Alla i Rust.

Skälet är detsamma varje gång: verktygen körs på varje sparning, i varje CI-körning, tusentals gånger om dagen. JavaScript i sig är inte tillräckligt snabbt för det arbetet och C++ är för dyrt att underhålla säkert. Rust hamnar mitt emellan.

Bun med sina 22 miljoner CLI-nedladdningar i månaden är det största projektet hittills som gör flytten. Prestandasiffrorna de själva redovisar ligger runt 59 026 förfrågningar per sekund på ett Express-baserat hello world-test på Linux x64 och drygt 2,5 miljoner WebSocket-meddelanden per sekund.

De sista 0,2 procenten avgör när Rust-versionen blir standard

De sista 0,2 procenten kompatibilitet på Linux x64 ska stängas. Sedan väntar macOS på både x64 och ARM, därefter Windows. Efter det en offentlig betaperiod. Något datum för när Rust-bygget ersätter Zig-bygget som standardbinär har inte kommunicerats.

Kör du Bun i produktion idag ändras alltså ingenting på kort sikt. 1.3.x-serien fortsätter komma från Zig-kodbasen. Den praktiska frågan är snarare vad du gör den dag betan öppnar: att testa din egen kodbas mot Rust-bygget tidigt är enda sättet att upptäcka om du råkar ligga i den där sista promillen av inkompatibilitet.

FAQ

Måste jag byta till Rust-versionen av Bun?

Nej. Rust-bygget är experimentellt och Zig-baserade 1.3.x fortsätter levereras som stabil version.

Blir Bun snabbare av omskrivningen?

Inte i första hand. Porten var mekanisk och arkitekturen är identisk, så målet var färre minnesbuggar snarare än högre genomströmning. Prestandavinster kan komma senare när Rust-specifika optimeringar görs men det är inte vad de elva dagarna handlade om.

Betyder det här att Zig är ett dåligt språk?

Nej och det är värt att skilja på saker här. Zig gav Bun den låga overhead projektet behövde från början. Problemet uppstod i mötet mellan Zigs manuella minneshantering och JavaScriptCores skräpsamling, plus att tillgången på Zig-kod för AI-modeller att lära sig från är begränsad. Båda faktorerna är specifika för just det här projektet.

Kan man skriva om vilket projekt som helst med AI på det här sättet?

Bara med en heltäckande testsvit på plats. Hela metoden byggde på att en existerande TypeScript-testsvit kunde avgöra om den nya koden betedde sig likadant som den gamla. Utan det facit finns inget sätt att verifiera en miljon rader maskingenererad kod.