Projek Bun menyelesaikan migrasi kod besar dari Zig ke Rust pada Mei 2026, dengan lebih daripada 1 juta baris perubahan kod dan 6,778 komit dalam masa 11 hari. Migrasi ini menggunakan 64 Claude secara selari, menghabiskan kos API sebanyak US$165,000. Selepas migrasi, masalah kebocoran memori telah diselesaikan secara mendasar; memori turun dari 6.7GB kepada 609MB selepas 2,000 build, dengan peningkatan prestasi 2% hingga 5% dan pengurangan saiz fail binari sebanyak kira-kira 20%. Namun, kod tersebut mengandungi sebanyak 13,000 kata kunci unsafe—178 kali ganda lebih banyak berbanding projek serupa—dengan 19 isu regresi yang diketahui, dan perubahan sebanyak 1 juta baris tidak mungkin dikaji secara manual oleh manusia. Bun kini telah diakuisisi oleh Anthropic.

Penulis artikel, sumber: InfoQ

Pada Mei 2026, projek Bun menyelesaikan pemindahan kod berskala besar yang hampir jarang berlaku dalam sejarah pembangunan perisian.

Pemindahan ini bermula pada 3 Mei dan secara rasmi digabungkan ke cabang utama pada 14 Mei, hanya mengambil masa 11 hari. Penulisan kod hanya mengambil masa 6 hari, dan keseluruhan prosesnya dibuat terbuka. Namun, Jarred Sumner mengambil hampir sebulan untuk menulis blog ringkasan, lebih lama daripada masa yang digunakan untuk menulis kod.

Runtime JavaScript ini asalnya mempunyai 535,496 baris kod Zig, tanpa termasuk komen; sementara itu, kira-kira 20% kod ditulis dalam C++ dan menyertakan beberapa pustaka C/C++. Kali ini, ia ditulis semula menjadi Rust dengan bantuan AI, proses ini melibatkan lebih daripada 1 juta perubahan baris kod, 6,778 komit, dan menjalankan sekitar 50 aliran kerja dinamik di Claude Code.

Berdasarkan data yang dinyatakan oleh Sumner, penulisan semula ini menghabiskan 5.9 miliar token input tanpa cache, 690 juta token output, dan 72 miliar pembacaan token input cache, dengan anggaran kos sebanyak $165,000 berdasarkan harga API.

Sumner mengatakan ini adalah batas terkini yang dapat dicapai oleh teknologi saat ini. Dia memperkirakan bahawa jika tiga jurutera yang sangat mahir dengan kod base Bun dilibatkan untuk melakukan migrasi ini secara manual, ia akan mengambil masa sekitar satu tahun, dan dalam tempoh itu, pasukan hampir tidak dapat meneruskan pembangunan ciri baru, pembaikan ralat, dan pembaikan keselamatan.

Selepas penulisan semula ini, Bun v1.3.14 akan menjadi versi Zig terakhir, dan Bun v1.4.0 akan menjadi versi Rust pertama.

1 Hasil: Dari kebocoran memori 6.7GB kepada stabil 609MB

Bun awalnya merupakan projek Zig dengan cakupan yang sangat luas: ia merupakan penterjemah JavaScript dan TypeScript, pembungkus, pengurus pakej, penggerak ujian, penyelesaian modul, klien HTTP dan WebSocket, serta mengimplementasikan lapisan API Node.js. Kekuatan produk ini menjadikan CLI Bun mempunyai lebih daripada 22 juta muat turun sebulan dan mendapat sokongan daripada projek atau syarikat seperti Vercel, Railway, DigitalOcean, Claude Code, dan OpenCode.

Namun, lebar yang sama ini juga membawa beberapa cabaran kepada Bun.

Dalam Bun v1.3.14, terdapat masalah yang telah lama mengganggu: semasa melaksanakan panggilan Bun.build() secara berterusan, memori akan terus bertambah dan tidak pernah dibebaskan. Setiap pembinaan bocor sekitar 3MB, yang kelihatan sedikit, tetapi jika anda menjalankan pelayan pembangunan di mana setiap permintaan memicu satu pembinaan, memori akan perlahan-lahan dimakan hingga proses gagal.

Dalam ujian sebenar, penggunaan memori ialah 1.9GB selepas 500 pembinaan, 3.5GB selepas 1000, 5.1GB selepas 1500, dan melonjak kepada 6.7GB selepas 2000.

Ini hanyalah puncak gunung es daripada banyak masalah memori. Dalam senarai pembaikan ralat v1.3.14, Sumner mencatatkan senarai panjang masalah:

Ketika memanggil .reset() dalam modul zlib, jika terdapat .write() asinkron yang sedang dijalankan di thread pool, proses akan gagal akibat "penggunaan selepas pelepasan heap"; dalam modul http2, callback JavaScript bersarang memicu pengulangan hash tabel, menyebabkan pointer aliran dalaman menjadi tidak sah; ketika UDPSocket.sendMany() sedang melalui iterasi, jika kod pengguna mengubah status sambungan soket melalui callback valueOf atau toString, ia akan menyebabkan penulisan melampaui sempadan; apabila pengagihan buffer output crypto.scrypt gagal, callback dan buffer kata laluan yang dilindungi tidak pernah dibebaskan; ......

Kesamaan antara bug-bug ini sangat jelas—hampir semuanya menunjuk kepada punca yang sama: menggabungkan GC dengan pengurusan memori manual dalam perisian yang sama.

Enjin moden seperti JavaScriptCore (dan V8) mempunyai peraturan yang sangat ketat terhadap penanganan pengecualian dan GC, manakala Zig tidak mengurus memori secara automatik seperti C. Apabila dua paradigma ini berada dalam proses yang sama, setiap pengagihan memori perlu ditinjau baris demi baris: di mana byte-byte ini dibebaskan? Bagaimana memastikan ia hanya dibebaskan sekali sahaja? Adakah pengecualian JavaScript diperiksa dengan betul? Adakah pointer yang dikelola oleh GC kelihatan kepada pemeriksa stak konservatif? Adakah ini memori yang dikelola oleh GC atau memori yang dikelola secara manual?

Yang lebih membingungkan ialah, pasukan bukan tidak berusaha. Mereka telah mengubah kompiler Zig, menambahkan sokongan Address Sanitizer (ASAN), menjalankan ujian ASAN dalam CI untuk setiap penghantaran, membina dengan ReleaseSafe di Windows, menjalankan ujian kabur 24/7 menggunakan Fuzzilli, serta banyak ujian end-to-end kebocoran memori. Walaupun begitu, laporan kerosakan masih terus berdatangan.

“Senarai pembaikan bug kami membuatkan kita merasa sangat buruk; saya bosan tidur dengan kebimbangan tentang kegagalan Bun,” tulis Sumner. Beliau tidak menyalahkan Zig—pengguna Zig lain tidak mengalami masalah seperti Bun, kerana mencampurkan GC dengan pengurusan memori manual adalah keperluan yang sangat jarang berlaku, dan hampir tiada bahasa yang direka untuk tujuan ini.

Versi Rust pula menghasilkan hasil: sama-sama menjalankan 2000 kali Bun.build(), memori stabil pada 609MB.

Selain masalah kebocoran memori telah diselesaikan secara mendasar, penulisan semula menggunakan Rust juga membawa peningkatan dalam beberapa dimensi lain.

Dalam hal kestabilan, v1.4.0 memperbaiki 128 bug yang boleh diperbanyak dari v1.3.14, termasuk kebocoran memori, kerosakan, dan ralat paparan warna pada teks bantuan.

Dari segi saiz, dengan penggantian Rust, perubahan ICU, dan pelipatan kod yang sama, saiz fail binari Bun berkurang sebanyak kira-kira 20% di Linux dan Windows.

Dari segi prestasi, terdapat peningkatan umum sebanyak 2% hingga 5%. Bun.serve meningkat dari 169,600 req/s kepada 177,700 req/s, dan node:http meningkat dari 103,800 kepada 108,500. Dalam aplikasi sebenar, next build berkurang dari 13.62 saat kepada 13.03 saat, dan tsc batch compile berkurang dari 0.94 saat kepada 0.89 saat.

Setelah Claude Code dilancarkan berdasarkan Rust Bun, masa pelancaran di Linux turun dari 517ms kepada 464ms, lebih pantas sebanyak kira-kira 10%.

2 kaedah: 64 Claude, 11 hari, 50 aliran kerja

Bagaimana Sumner melakukannya, ini mungkin bahagian yang paling patut diperhatikan—kerana kaedah yang digunakannya berbeza daripada “meminta AI menulis kod” secara tradisional.

Sumner membahagikan keseluruhan proses menjadi sekitar 50 aliran kerja dinamik, setiap aliran kerja merupakan satu kitaran. Beliau menggambarkan corak ini dengan pseudokod dalam blognya:

Setiap tugas mempunyai konteks (contohnya, tiket Jira atau isu GitHub), Claude menulis kod berdasarkan konteks ini, kemudian dua pemeriksa (juga Claude) memeriksa kod, dan akhirnya menerapkan maklum balas. Selepas selesai, tugas seterusnya diambil.

Pola ini berterusan sepanjang proses penulisan semula. Setiap alur kerja bertanggungjawab atas satu sasaran tertentu:

• Hasilkan panduan porting yang memetakan corak dan jenis Zig ke corak dan jenis Rust;
• Mengimpor setiap fail .zig secara mekanikal ke dalam satu fail .rs, dan sepadankan dengan PORTING.md dan LIFETIMES.tsv;
• Memperbaiki ralat kompilasi setiap crate;
• Jalankan subcommand seperti bun test atau bun build;
• Pastikan semua ujian dalam keseluruhan suite ujian Bun berjaya; lakukan beberapa putaran pengecilan dan pembersihan besar-besaran.

Pada puncaknya, Sumner menjalankan 4 alur kerja secara serentak, dengan 16 Claude dalam setiap alur kerja, menjadikan 64 Claude bekerja secara selari dalam 4 pokok alur kerja, masing-masing menghantar dan mendorong fail. Pada puncak tertinggi, Claude menulis sekitar 1,300 baris kod setiap minit.

Pemisahan reka bentuk “pembuat / pemeriksa” ini adalah kunci. Claude yang menulis kod ingin kod itu diterima, sama seperti jurutera manusia yang mempunyai bias. Oleh itu, pemeriksa dan pembuat dipisahkan sepenuhnya—pemeriksa hanya melihat perbezaan kod, bukan proses penalaran pembuat, dan diberitahu secara jelas “andaikan kod itu salah”. Setiap pembuat dipasangkan dengan lebih daripada dua pemeriksa yang bersifat adversarial, dan tugas tunggal pemeriksa ialah mencari bug.

Menulis kod hanyalah langkah pertama. Kod Zig adalah unit kompilasi tunggal, manakala Rust perlu dipisahkan menjadi sekitar 100 crate untuk mempercepat proses kompilasi, dan ketergantungan berputar menyebabkan cargo check mengeluarkan sebanyak 16,000 ralat kompilasi sekaligus. Ini adalah bencana bagi seorang individu, tetapi bagi 64 Claude yang bekerja secara selari, ini adalah antrean kerja yang boleh ditangani. Alur kerja mengelompokkan ralat mengikut crate, setiap crate dijalankan cargo check, satu Claude memperbaiki, dua orang mengulas, dan satu orang menerapkan perubahan.

Seterusnya, jalankan bun --version, kemudian bun test. Aliran ujian menjalankan 100 fail ujian secara rawak setiap kali, dipecahkan kepada 4 pokok kerja. Set ujian juga mengandungi pelbagai jenis: beberapa ujian berjalan lebih daripada satu minit, beberapa menghabiskan bilangan sambungan TCP sistem, dan beberapa mencabang sebanyak 10000 proses. Sumner menggunakan systemd-run untuk mencipta cgroup bagi menghadkan sumber, tetapi mesin masih gagal berulang kali akibat ruang cakera tidak mencukupi.

Dua hari kemudian, ujian gagal pada platform Linux berkurang dari 972 menjadi 23. Satu setengah hari selepas itu, Linux semuanya hijau. Lima hari kemudian, keenam-enam platform—Linux x64, Linux arm64, macOS x64, macOS arm64, Windows x64, Windows arm64—semuanya lulus.

Pada 14 Mei, PR #30412 secara rasmi digabungkan, semua ujian berjalan lulus tanpa melepasi atau membuang sebarang ujian.

3 Kekhawatiran: 13,000 kod tidak selamat dan tidak boleh diperiksa baris demi baris

Namun, Sumner juga mengakui bahawa kerja ini belum benar-benar selesai.

Sehingga kini, sekitar 4% kod Rust Bun berada di dalam blok unsafe, dengan sekitar 13,000 kata kunci unsafe yang tersebar di sekitar 27,000 baris kod, manakala jumlah keseluruhan kod Rust adalah sekitar 780,000 baris. 78% blok unsafe hanya terdiri daripada satu baris, biasanya satu pointer dari C++ atau satu panggilan ke pustaka C.

Dia menganggap bahawa reka semula seterusnya akan menurunkan nisbah ini. Tetapi ada yang mengira: uv mempunyai sekitar 350,000 baris kod, dengan hanya 73 panggilan unsafe. Jumlah unsafe Bun adalah 178 kali ganda uv. Perbezaan ini sukar dijelaskan dengan "perlu memanggil pustaka C".

Dan kemudian juga mengekspos perilaku tak terdefinisi dalam kod Rust yang selamat. Ia lebih sukar untuk diselidiki berbanding C++, kerana anda akan menganggap kod selamat tidak mungkin mengalami masalah.

Tim Bun kemudian mengubah PathString::init dalam masalah ini menjadi unsafe fn.

Sumner sendiri mengakui bahawa penulisan semula ini memperkenalkan 19 isu regresi yang diketahui, dan menyatakan bahawa kebanyakan isu regresi berasal dari kod yang mempunyai tatabahasa yang sama tetapi makna yang berbeza.

Contoh dua potong kod ini kelihatan serupa, tetapi tingkah laku mereka sangat berbeza. Assert Zig adalah satu fungsi, oleh itu parameternya akan dijalankan pada setiap pembinaan. Debug_assert! Rust adalah satu makro, oleh itu dalam versi rilis, seluruh ungkapan (termasuk panggilan fungsi) akan dihapus insert_stale.

Walaupun semua masalah telah diperbaiki, ini tidak bermakna bahawa kod AI berjuta-juta baris tidak mempunyai masalah lain.

Siapa orang waras yang akan memindahkan aplikasi produksi mereka segera selepas runtime ditulis semula sepenuhnya? Jika anda menganggap versi 1.4 tidak membawa bug baru atau perubahan tingkah laku, anda terlalu naif.

Satu perkara yang tidak boleh diabaikan ialah tinjauan kod. Perubahan sebanyak satu juta baris tidak mungkin diperiksa secara manual baris demi baris—sekiranya satu baris diambil satu minit, ia akan memerlukan 11.7 hari berturut-turut; mengikut kadar tinjauan kod sebenar (200 baris sejam), ia akan mengambil lebih daripada dua tahun untuk selesai.

Pemeriksa PR kali ini terutama adalah claude[bot] dan coderabbitai[bot]. Sumner sendiri mengakui bahawa cara pemeriksaannya adalah “memeriksa sama ada agen pemeriksaan adversarial dapat menangkap perbezaan dengan betul, memastikan panduan transformasi dipatuhi, sambil secara manual membaca banyak kod juga”. Tetapi “banyak” berapa banyak, dia tidak nyatakan.

Masih ada satu isu yang tidak boleh dielakkan: Bun telah diambil alih oleh Anthropic pada Disember 2025, dan alat yang benar-benar mampu menyelenggarakan repositori kod ini pada dasarnya hanyalah Claude itu sendiri. Sesetengah ahli komuniti berpendapat, ini sudah tidak lagi dianggap sebagai projek sumber terbuka dalam erti kata tradisional—jika anda ingin menghantar PR kepada Bun, anda perlu berlanggan Anthropic, atau bergantung pada beberapa ahli inti yang telah memahami kod yang dihasilkan AI.

Adakah senilai 165.000 dolar AS untuk satu tahun kerja?

Sumner juga mengungkap dalam blognya bahawa kos penulisan semula API ini kira-kira US$165,000, setara dengan satu tahun kerja tiga jurutera. Nombor ini memicu perbincangan sengit di Hacker News.

Ada yang berpendapat bahawa perbelanjaan ini sebenarnya sangat berbaloi. Dengan 165,000 dolar AS, anda tidak boleh mempekerjakan banyak jurutera penuh masa di Silicon Valley, apalagi jurutera dari syarikat seperti Anthropic. Berdasarkan data gaji di levels.fyi, jumlah kompensasi jurutera Anthropic kemungkinan mencapai 500,000 dolar AS atau lebih. Sekiranya dihitung secara kasar dengan purata gaji tahunan 336,000 dolar AS untuk 50 jurutera, ia bersamaan dengan kira-kira 1,292 dolar AS sehari. Dengan 50 orang bekerja secara berterusan selama 11 hari, kos tenaga kerja sahaja hampir mendekati 710,000 dolar AS, belum termasuk faedah, tempat pejabat, peralatan, dan perbelanjaan pengurusan lain.

Namun, Sumner menggunakan versi pra-rilis Claude Fable 5, model canggih yang belum dibuka kepada awam dan mungkin tunduk kepada pengawasan eksport. Oleh itu, harga API hanyalah nombor yang dilihat oleh pengguna akhir, sementara di belakangnya terdapat perbelanjaan besar dalam penyelidikan dan pembangunan oleh Anthropic. Ada pula yang menunjukkan bahawa menyederhanakan kos menjadi harga API adalah usaha sengaja untuk meredahkan penglibatan sebenar. Jika mempertimbangkan kos pembangunan model, kos latihan, peruntukan komputasi, dan tenaga kejuruteraan, percaya bahawa jumlah kos keseluruhan pasti sangat tinggi, kemungkinan besar melebihi $1.5 juta.

Dan pada pandangan semasa, walaupun US$165,000 untuk satu tahun kerja kelihatan sangat berbaloi secara perakaunan.

Tetapi kos sebenar tidak tertera dalam bil ini. Repositori ini mempunyai 6,778 commit, dan tiada seorang pun yang membacanya secara keseluruhan dari awal hingga akhir. Walaupun semuanya berjalan lancar sekarang, bagaimana pula enam bulan kemudian? Apabila masalah konkuren yang aneh muncul tiba-tiba pada pukul 3 pagi, jurutera yang bertugas menghadapi sistem yang bahkan dirinya sendiri tidak mampu menjelaskan logik dalamanya. Dalam jangka panjang, ia akan terus dipelihara oleh AI—bagaimana cara mengira kos pemeliharaan ini sebenarnya cukup sukar.