Nakumpleto ng Bun ang malaking paglipat mula sa Zig patungo sa Rust noong Mayo 2026, na nagbago ng higit sa isang milyong linya ng code at 6,778 na commits sa loob ng 11 araw. Ginamit ang 64 na Claude para magtrabaho nang paralelo, na nagkost ng $165,000 sa API. Naresolba ang mga problema sa memory leak pagkatapos ng paglipat, mula sa 6.7 GB hanggang sa matatag na 609 MB pagkatapos ng 2,000 na build, na nagdala ng pagpapabuti sa performance ng 2% hanggang 5%, at pagbabawas ng laki ng binary file ng halos 20%. Gayunpaman, mayroon pa ring halos 13,000 na unsafe keywords sa code, na 178 beses ang dami kumpara sa mga katulad na proyekto, may 19 kilalang regression issues, at hindi maaaring suriin ng tao ang bawat linya ng isang milyong pagbabago. Kasalukuyang binili na ng Anthropic ang Bun.

May-akda ng artikulo, pinagkukunan: InfoQ

Noong Mayo 2026, natapos ng proyekto ng Bun ang isang malawakang paglipat ng code na halos kakaibang pangyayari sa kasaysayan ng software development.

Ang pagmigrasyon na ito ay nagsimula noong Mayo 3 at opisyal na pinagsama sa main branch noong Mayo 14, na nagtagal lamang ng 11 araw. Ang pagsusulat ng code ay nagtagal lamang ng 6 araw, at ang buong proseso ay publiko. Gayunpaman, ang pagpapalabas ng blog post ni Jarred Sumner ay nagtagal ng halos isang buwan—mas mahaba kaysa sa oras na ginugol sa pagsusulat ng code.

Ang orihinal na JavaScript runtime ay may 535,496 na linya ng Zig code, hindi kasama ang mga komento; samantala, halos 20% ng code ay isinulat sa C++ at binuo ang maraming C/C++ library. Sa pagrere-write nito gamit ang AI bilang Rust, ang proseso ay nagsasangkot ng higit sa isang milyong linya ng pagbabago, 6,778 na commits, at pagsasagawa ng halos 50 dynamic workflows sa Claude Code.

Batay sa datos na inilabas ni Sumner, ang pag-revise na ito ay nag消耗 ng 5.9 bilyong uncached input tokens, 690 milyong output tokens, at 72 bilyong cached input token reads, na nagkakahalaga ng humigit-kumulang $165,000 batay sa API pricing.

Sinabi ni Sumner na ito ang pinakamataas na antas na natutupad ng kasalukuyang teknolohiya. Ipinagpalagay niya na kung gagawin ng 3 na inhenyero na lubos na pamilyar sa codebase ng Bun, magkakaroon ito ng isang taon upang makumpleto ang migration, at sa loob ng taong iyon, halos hindi makapagpapatuloy ang team sa pagpapalawak ng mga bagong feature, pagpapabuti ng mga bug, at pagpapabuti ng seguridad.

Pagkatapos ng pag-revise na ito, ang Bun v1.3.14 ay magiging huling bersyon na Zig, at ang Bun v1.4.0 ay magiging unang bersyon na Rust.

1. Resulta: Mula sa 6.7GB na memory leak patungo sa 609MB na stable

Ang Bun ay isang proyekto ng Zig mula sa simula, na may malawak na sakop: ito ay isang transpiler para sa JavaScript at TypeScript, isang bundler, isang package manager, isang test runner, isang module resolver, isang HTTP at WebSocket client, at nagpapatupad din ng Node.js API layer. Dahil sa ganitong kalawakan ng produkto, ang CLI ng Bun ay may higit sa 22 milyong download bawat buwan at sinuportahan ng mga proyekto o kumpanya tulad ng Vercel, Railway, DigitalOcean, Claude Code, at OpenCode.

Ngunit ang parehong lapad ay nagdala rin ng ilang hamon kay Bun.

Lalo na sa Bun v1.3.14, may isang problema na nagdudulot ng pagod sa marami: habang patuloy na tinatawag ang Bun.build(), ang memorya ay patuloy na nagkukumpuni at hindi nagpapalabas. Halos 3MB ang leakage bawat build, maliit ito sa tingin, ngunit kung ikaw ay gumagamit ng development server kung saan bawat request ay nagtatrabaho ng isang build, ang memorya ay magkakaroon ng paulit-ulit na pagkawala hanggang sa mabagsik ang proseso.

Sa tunay na pagsubok, ang paggamit ng memorya ay 1.9GB pagkatapos ng 500 na build, 3.5GB pagkatapos ng 1000, 5.1GB pagkatapos ng 1500, at tumalon sa 6.7GB pagkatapos ng 2000.

Ito ay kahit anong bahagi ng isang malaking problema sa memorya. Sa listahan ng mga pag-aayos ng bug sa v1.3.14, tinala ni Sumner ang isang mahabang lista ng mga problema:

Kapag tinatawag ang .reset() sa zlib module habang may isang asynchronous .write() na nasa thread pool, ang proseso ay maaaring mabasag dahil sa "heap use-after-free"; ang nested JavaScript callback sa http2 module ay nagtrigger ng rehashing ng hash table, na nagresulta sa pagkawala ng internal stream pointer; habang binabasa ng UDPSocket.sendMany(), kung ang user code ay nagbago ng connection state ng socket sa pamamagitan ng valueOf o toString callback, maaaring mangyari ang out-of-bounds write; kapag nabigo ang crypto.scrypt sa pag-alok ng output buffer, ang callback at ang protected password buffer ay hindi mai-release...

Ang pangkalahatang katangian ng mga bug na ito ay malinaw—halos lahat nito ay nagtuturo sa iisang pinagmulan: ang pagpapalit ng GC at manual memory management sa iisang software.

Ang modernong mga engine tulad ng JavaScriptCore (at V8) ay may napakatigat na mga patakaran sa pag-handle ng exception at GC, samantalang ang Zig ay hindi awtomatikong nagpapamahala ng memorya tulad ng C. Kapag ang dalawang paraan na ito ay nasa iisang proseso, kailangang suriin nang isang linya ang bawat pag-alok ng memorya: saan binubura ang mga byte na ito? Paano masisiguro na bawas isang beses lamang ito binubura? Tama ba ang pagsusuri sa JavaScript exception? Nakikita ba ng conservative stack scanner ang pointer na ito na pinamamahalaan ng GC? Ito ba ay GC memorya o manual na pinamamahalaang memorya?

Mas nakakapagod pa ang katotohanan na ang koponan ay hindi nagawa ang anumang pagsisikap. Nagawa na nila ang pagbabago sa Zig compiler, idinagdag ang suporta para sa Address Sanitizer (ASAN), tinataasan ang ASAN tests sa bawat commit sa CI, ginagamit ang ReleaseSafe build sa Windows, ginagamit ang Fuzzilli para sa 24/7 fuzz testing, at maraming end-to-end na pagsubok para sa memory leaks. Gayunpaman, patuloy pa ring dumadating ang mga ulat ng crash.

“Ang listahan ng aming bug fixes ay nagdudulot ng masamang pakiramdam, at napapagod na ako sa pagtulog habang nag-aalala tungkol sa pagkabagsak ng Bun,” ayon kay Sumner. Hindi niya pinipilit ang Zig—hindi nagkakaroon ng ganitong problema ang iba pang mga gumagamit ng Zig, dahil ang pagpapalit ng GC at manual memory management ay isang napakakakaibang pangangailangan, at karamihan sa mga wika ay hindi ito isinasaalang-alang.

Ang resulta ng Rust version ay: habang isinasagawa ang 2000 beses ang Bun.build(), ang memorya ay nanatili sa 609MB.

Bukod sa paglutas ng problema sa memory leak, ang pag-rewrite sa Rust ay nagdala rin ng iba pang mga pagpapabuti sa iba’t ibang aspeto.

Sa kahusayan, inayos ng v1.4.0 ang 128 na bug na maaaring maulit sa v1.3.14, mula sa memory leak hanggang sa crash at mali na pagkakalabas ng kulay sa tulong na teksto.

Batay sa laki, kasama ang pag-rewrite sa Rust, mga pagbabago sa ICU, at parehong code folding, bumaba ang laki ng binary ng Bun sa Linux at Windows ng humigit-kumulang 20%.

Sa aspeto ng performance, nagkaroon ng pangkalahatang pagpapabuti ng 2% hanggang 5%. Ang Bun.serve ay tumataas mula sa 169,600 req/s hanggang sa 177,700 req/s, habang ang node:http ay umakyat mula sa 103,800 hanggang sa 108,500. Sa mga praktikal na aplikasyon, bumaba ang next build mula sa 13.62 segundo hanggang sa 13.03 segundo, at ang tsc batch compilation ay bumaba mula sa 0.94 segundo hanggang sa 0.89 segundo.

Pagkatapos ng paglalabas ng Claude Code sa base na Rust Bun, bumaba ang oras ng pag-start sa Linux mula sa 517ms hanggang 464ms, mas mabilis ng halos 10%.

2 paraan: 64 na Claude, 11 araw, 50 na workflow

Paano ni Sumner ito ginawa, ito ang posibleng pinakamahalagang bahagi—dahil sa paraan na kanyang ginamit, na iba sa tradisyonal na “pagsusulat ng code ng AI”.

Ipinakita ni Sumner ang buong proseso bilang mga halos 50 na dinamikong workflow, bawat isa ay isang loop. Ginamit niya ang pseudocode sa kanyang blog upang ilarawan ang pattern na ito:

Mayroong konteksto bawat gawain (tulad ng isang Jira ticket o GitHub issue), isusulat ni Claude ang code batay sa kontekstong iyon, pagkatapos ay sinusuri ng dalawang reviewer (kung saan ay Claude rin) ang code, at sa huli ay inaapply ang feedback. Pagkatapos makumpleto, susundin ang susunod na gawain.

Ang ganitong modelo ang sumasaklaw sa buong proseso ng pag-revise. Bawat workflow ay responsable sa isang tiyak na layunin:

• Gumawa ng isang porting guide na nagpapalit ng mga pattern at uri ng Zig sa mga pattern at uri ng Rust;
• Isalin ang bawat .zig file nang mekanikal na paraan sa isang .rs file, at tugmaan ang PORTING.md at LIFETIMES.tsv;
• Iayos ang bawat compilation error sa crate;
• Paganapin ang mga subcommand tulad ng bun test o bun build;
• Gawin maging lahat ng mga pagsubok sa buong test suite ng Bun na magtagumpay; gawin ang ilang round ng malalaking restructuring at paglinis.

Sa pinakamataas na punto, nagpapatakbo si Sumner ng 4 na workflow, kada isa ay may 16 na Claude, kaya kabuuang 64 na Claude ang nagtatrabaho nang sabay-sabay sa 4 na tree ng trabaho, at nagpapadala at nagpapush ng mga file. Sa pinakamataas na punto, isinulat ng Claude ng humigit-kumulang 1,300 na linya ng code bawat minuto.

Ang paghihiwalay ng disenyo na “implementer / reviewer” ay mahalaga. Ang Claude na sumusulat ng code ay may bias tulad ng mga human engineer na nais na tanggapin ang kanilang code. Kaya ang reviewer at implementer ay ganap na hiwalay—ang reviewer ay tumitingin lamang sa code differences, hindi sa proseso ng pag-iisip ng implementer, at binigyan ng malinaw na paalala na “ipagpalagay na mali ang code.” Bawat implementer ay may higit sa dalawang adversarial reviewer, at ang tanging gawain ng reviewer ay ang paghahanap ng bug.

Ang pagsulat ng code ay lang isang unang hakbang. Ang Zig code ay isang solong compilation unit, habang ang Rust ay kailangang hatiin sa halos 100 crates para mabilis ang compilation, at ang mga cyclic dependencies ay nagdudulot ng pagkakalabas ng halos 16,000 compilation errors sa isang pagkakataon sa cargo check. Para sa isang tao, ito ay isang kalamangan, ngunit para sa 64 na paralel na gumagana na Claude, ito ay isang maipapasa na queue ng trabaho. Ang workflow ay nagpapangkat ng mga error ayon sa bawat crate, bawat crate ay pinapagalaw ang cargo check, isang Claude ang nag-aayos, dalawa ang pagsusuri, at isang itinatapat ang mga pagbabago.

Susunod ay patakbuhin ang bun --version, pagkatapos ay ang bun test. Ang test workflow ay random na patakbuhin ang 100 test files, na hinati sa 4 na work trees. Ang test suite ay naglalaman rin ng iba’t ibang uri: ilang test ay tumatagal ng higit sa isang minuto, ilan ay nagpapalabas ng lahat ng system TCP connections, at ilan ay fork ng humigit-kumulang 10,000 processes. Gumamit si Sumner ng systemd-run upang lumikha ng cgroup para limitahan ang mga resource, ngunit patuloy pa ring bumagsak ang machine dahil sa kakulangan sa disk space.

Dalawang araw pagkatapos, bumaba ang bilang ng mga nagkamali sa pagsubok sa platform na Linux mula sa 972 patungo sa 23. Isang araw at kalahati pagkatapos, ganap na green na ang Linux. Limang araw pagkatapos, lahat ng anim na platform—Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, at Windows arm64—lahat ay nakapasa.

Mayo 14, ang PR #30412 ay opisyal na isinama, at lahat ng test suite ay nakapasa, walang sinasaklaw o tinanggal na test.

3 Mga lihim na banta: 13,000 mga unsafe at hindi maaring i-review na code

Gayunpaman, kilala rin ni Sumner na ang trabaho ay hindi pa talaga natatapos.

Hanggang sa kasalukuyan, ang halos 4% ng Rust code ng Bun ay nasa loob ng unsafe block, na may halos 13,000 na unsafe keyword na nakalat sa halos 27,000 na linya ng code, habang ang kabuuang dami ng Rust code ay halos 780,000 na linya. Ang 78% ng unsafe block ay may isang linya lamang, karaniwan ay isang pointer mula sa C++ o isang tawag sa C library.

Inaasahan niya na ang susunod na restructure ay magdedecrease sa ratio na ito. Ngunit may isang tao ang nagkalkula: ang uv ay may halos 350,000 linya ng code, at mayroon lamang 73 beses ang unsafe call. Samantalang ang bilang ng unsafe sa Bun ay 178 beses ang dami ng uv. Mahirap ipaliwanag ang pagkakaiba na ito gamit ang “kailangan ng pag-call sa C library.”

At sinabi rin ang undefined behavior sa ligtas na Rust code. Mas mahirap i-debug kaysa sa C++, dahil isipin mo na imposible na may mali sa ligtas na code.

Ang koponan ng Bun ay nagbago pagkatapos ang PathString::init sa unsafe fn.

Admito rin ni Sumner na ang pag-rewrite na ito ay nagdulot ng 19 na kilalang regression issues, at sinabi niya na ang karamihan sa mga regression issue ay nagmula sa code na may parehong grammar ngunit iba't ibang kahulugan.

Halimbawa, ang dalawang code snippet na ito ay tila magkakatulad, ngunit iba ang kanilang pag-uugali. Ang Zig code na assert ay isang function, kaya ang mga parameter nito ay tumatakbo sa bawat build. Ang Rust code na debug_assert! ay isang macro, kaya sa release version, ang buong expression (kabilang ang function call) ay tatanggalin insert_stale.

Kahit na nalutas na ang lahat ng mga problema, hindi ito nangangahulugan na wala nang iba pang mga problema sa milyon-milyong linya ng AI code.

Sino ba ang normal na tao ay magmigrate agad ng production application niya pagkatapos ng isang buong pagrerewrite ng runtime? Masyadong nakakabaliw ang paniniwala na ang version 1.4 ay walang bagong bug o pagbabago sa pag-uugali.

Isang bagay na hindi maaaring kalimutan ay ang code review. Ang 1 milyong linya ng pagbabago ay hindi posible na tingnan ng tao nang isang linya sa isang beses—kahit isang minuto bawat linya, kailangan mong magpatuloy na tingnan nang 11.7 araw; ayon sa tunay na bilis ng code review (200 linya bawat oras), kailangan ng higit sa dalawang taon upang matapos.

Ang mga tagapagsuri sa PR na ito ay pangunahin ang claude[bot] at coderabbitai[bot]. Acknowledges din ni Sumner na ang kanyang paraan ng pagsusuri ay “sinuri kung tama ang pagkuha ng mga pagkakaiba ng adversarial review agent, siniguro na sinusunod ang mga gabay sa pagkakasunod, habang sarili ring binasa niya ang maraming code.” Ngunit hindi niya sinabi kung gaano karami ang “marami”.

May isa pang hindi maiiwasang tanong: Kinuha ni Anthropic ang Bun noong Disyembre 2025, at ang tanging totoong epektibong tool para sa pagpapanatili ng codebase na ito ay ang Claude mismo. Sinasabi ng ilan sa komunidad na hindi na ito kabilang sa tradisyonal na open-source project—kung gusto mong mag-submit ng PR para sa Bun, kailangan mong mag-subscribe sa Anthropic, o mag-asa sa ilang mga pangunahing miyembro na naiintindihan na ang AI-generated code.

Kabutihan ba ng $165,000 para sa isang taon ng trabaho?

Isinagawa rin ni Sumner sa blog na ang gastos sa pag-rewrite ng API ay halos $165,000, katumbas ng isang taong trabaho ng 3 na engineer. Ang numero na ito ay nagdulot ng matinding diskusyon sa Hacker News.

May mga tao na naniniwala na ang gastos na ito ay talagang mabisa. Hindi maaaring makakuha ng maraming full-time engineer sa Silicon Valley ng $165,000, lalo na ang mga engineer mula sa antas ng Anthropic. Ayon sa data sa levels.fyi, ang kabuuang kompensasyon ng isang engineer sa Anthropic ay malamang ay umabot sa $500,000 o higit pa. Kahit na gamitin ang simpleng pagkalkula na ang average taunang sahod ng 50 engineer ay $336,000, ang halaga nito ay umabot sa halos $1,292 bawat araw. Para sa 50 tao na nagtrabaho nang tuloy-tuloy sa loob ng 11 araw, ang gastos sa manpower ay nakaabot na halos $710,000, at hindi pa kasama ang mga benepisyo, espasyo sa opisina, kagamitan, at iba pang gastos sa administrasyon.

Gayunpaman, ginamit ni Sumner ang “pre-release version ng Claude Fable 5,” isang mataas na modelo na hindi pa available sa publiko at posibleng pailalim sa export controls. Kaya ang API pricing ay simpleng numero na nakikita ng huling user, ngunit sa likod nito ay ang malaking gastos sa R&D na inilalabas ni Anthropic. May mga tao ring nagturo na ang pagpapakaliwa ng gastos bilang API pricing ay isang pagsisikap na palakihin ang totoong pagkakalagay. Kung isasama ang gastos sa pagbuo ng modelo, pagtratap, paggamit ng computing power, at engineering manpower, naniniwala kami na ang kabuuang gastos ay lubos na mataas, malamang hihigit sa $1.5 milyon.

At sa kasalukuyan, bagaman ang $165,000 para sa isang taong paggawa ay tila mabuting halaga sa papel.

Ngunit ang totoong gastos ay hindi nakalista sa pahina na ito. May 6,778 na commits ang codebase na hindi binasa ng sinuman nang buo mula sa simula hanggang sa wakas. Bagaman lahat ay nasa tamang landas ngayon, ano ang mangyayari sa loob ng anim na buwan? Kapag biglang lumabas ang isang kakaibang concurrency issue sa 3:00 AM, ang engineer na on-call ay makakatok sa isang sistema na kahit siya mismo ay hindi kayang ipaliwanag ang lohika nito. Paglalawak nito sa hinaharap, kailangan itong mapanatili ng AI—paano isasama ang gastos sa pagpapanatili? Talagang mahirap i-calculate.