Versi penulisan ulang Rust eksperimental dari Bun mencapai kompatibilitas pengujian 99,8% di Linux x64 glibc

• Versi penulisan ulang Rust dari Bun lulus 99,8% dari suite pengujian yang ada di lingkungan Linux x64 glibc
• Basis kodenya “pada dasarnya adalah basis kode yang sama”, dan dengan transisi ke Rust, compiler dapat memaksa siklus hidup tipe serta memungkinkan penggunaan destruktor pada saat yang diperlukan
• Bagian yang tidak aman menjadi lebih jelas melalui unsafe di Rust, yang berdampak mendorong refaktorisasi
• Alasan penulisan ulang ini adalah karena lelah menghabiskan banyak waktu untuk mengkhawatirkan dan memperbaiki kebocoran memori, crash, dan masalah stabilitas, serta menginginkan bahasa yang menyediakan alat lebih kuat untuk mencegahnya
• Skala keseluruhannya disebut sebagai penulisan ulang 960.000 LOC, dan setelah lulus suite pengujian di Linux, platform lain juga akan segera menjadi target

---

Status penulisan ulang Rust

• Versi penulisan ulang Rust dari Bun lulus 99,8% dari suite pengujian yang ada di lingkungan Linux x64 glibc
• Basis kodenya “pada dasarnya adalah basis kode yang sama”, dan saat diubah ke Rust, compiler dapat memaksa siklus hidup tipe dan memungkinkan penggunaan destruktor pada saat yang diperlukan
• Bagian yang tidak aman terlihat lebih jelas sebagai unsafe di Rust, yang berdampak mendorong refaktorisasi
• Latar belakang penulisan ulang ini adalah rasa lelah karena menghabiskan banyak waktu untuk mengkhawatirkan dan memperbaiki kebocoran memori, crash, dan masalah stabilitas, serta keinginan agar bahasa tersebut menyediakan alat yang lebih kuat untuk mencegah masalah seperti ini
• Skala keseluruhannya disebut sebagai penulisan ulang 960.000 LOC, dan kodenya benar-benar berjalan, lulus suite pengujian di Linux, dan platform lain juga akan segera menjadi target

Hal yang akan diungkap berikutnya dan jawaban terkait build

• Arti perubahan ini bagi Bun, benchmark, penggunaan memori, kemudahan pemeliharaan ke depan, dan proses penulisan ulang yang sebenarnya akan dibahas dalam tulisan blog terpisah
• Proses penulisan ulang ini bukan sekadar mengatakan “claude, rewrite bun in rust. make no mistakes”, dan pekerjaan untuk mencapai kondisi yang benar-benar berfungsi mulai dilakukan sejak 6 hari lalu
• Disebutkan bahwa jika dilakukan sepenuhnya secara manual, beban kerjanya akan sangat besar
• Waktu kompilasi pada dasarnya mirip dengan versi Zig yang ada saat ini yang menggunakan compiler Zig yang lebih cepat, dan disebutkan bahwa jika menggunakan compiler Zig upstream, port Rust akan terkompilasi lebih cepat
• Performa akan dibahas dalam tulisan blog terpisah
• Mengenai langkah berikutnya untuk mengganti libc itu sendiri dengan versi Rust, yaitu frankenlibc, disebutkan bahwa sebelum itu ia akan membuat libc sendiri

[GN⁺]

Komentar Hacker News

• Empat hari lalu juga ada pembahasan seperti ini: https://news.ycombinator.com/item?id=48019226
  Seorang kontributor Bun bilang itu cabangnya sendiri; thread waktu itu adalah reaksi berlebihan terhadap kode yang belum berfungsi, mereka belum pernah memutuskan untuk melakukan penulisan ulang, dan ada kemungkinan besar seluruh kodenya akan dibuang
  Katanya mereka ingin melihat seperti apa versi yang benar-benar berjalan, bagaimana performa dan maintainability-nya, serta seberapa sulit meloloskan test suite Bun, lalu membandingkan versi Rust dan versi Zig secara berdampingan

  • Saat menulis pesan itu, cargo check menghasilkan lebih dari 16.000 error compiler, dan bahkan belum bisa menampilkan nomor versi maupun menjalankan JavaScript
    Dia juga tidak menyangka ini akan berfungsi secepat ini, atau performanya akan sekompetitif ini, dan detailnya akan ditulis dalam sebuah posting blog
  • Sepertinya mereka sudah mengecek maintainability, performa, dan hasil test suite sebelum mengambil keputusan
  • Kalau begitu, sampai saat ini itu berarti sangat sukses sebagai eksperimen
  • Beberapa hari lalu dia juga bilang, “open source tampaknya akan bergerak ke arah sebaliknya. Kontribusi manusia dilarang. slop akan menjadi artefak nostalgia dari 2025~2026”
    Setelah diakuisisi Anthropic mungkin seharusnya sudah bisa diduga, tapi tetap mengecewakan. Bukan berarti saya menentang teknologi model bahasa besar itu sendiri, tetapi cara perusahaan-perusahaan “AI” ini memperoleh kekuasaan dengan melahap industri perangkat lunak dan masyarakat secara luas terasa menjijikkan, dan menciptakan ketergantungan yang sangat tidak sehat
    Kita perlu berpikir beberapa langkah ke depan dan menyiapkan stack perangkat lunak dan komunitas tanpa slop. Termasuk Zig dan ekosistemnya. Walaupun kita dan generasi mendatang mungkin tidak bisa sepenuhnya hidup tanpa slop, memastikan budaya komputasi yang berkelanjutan dengan kebebasan sebagai kebebasan menjadi lebih penting daripada sebelumnya

• Sangat mengesankan kalau ini bisa dicapai secepat itu. Saya sedang mengerjakan proyek serupa, mem-port TypeScript ke Rust, dan sekarang sudah masuk bulan kelima, tapi tanpa Mythos dan akses token tanpa batas
  Meski begitu, tingkat kelulusannya sudah hampir 100%, dan saat ini 99,6%: https://tsz.dev
  Rust sangat cocok untuk menulis kode dengan model bahasa besar. Berkat sistem tipenya yang ketat, model jadi lebih jarang membuat kesalahan sangat bodoh yang di bahasa lain mungkin lolos begitu saja
  Tapi menulis kode dengan model bahasa besar tidak menghilangkan kebutuhan akan visi desain dan penilaian trade-off saat membangun proyek. Karena itu Jarred dan timnya adalah orang yang tepat untuk memanfaatkan kode dalam jumlah besar yang ditulis dengan model bahasa besar

  • Pemaksaan invariant Rust saat compile time membantu model bahasa besar menghasilkan kode yang berjalan karena memberi umpan balik cepat dan memungkinkan perbaikan cepat
    Di sisi lain, Rust adalah bahasa yang kompleks sehingga perubahan kecil mudah memicu longsoran refactoring yang memaksa perombakan kode di tempat yang jauh. Kalau arsitektur awalnya buruk atau kurang matang, ada risiko besar basis kodenya berubah jadi spaghetti seiring model bahasa besar memperbesar codebase secara bertahap seperti biasanya
    Pada akhirnya saya khawatir hasilnya akan menjadi program yang memang bisa dikompilasi dan dijalankan, tetapi tidak bisa dibaca atau dipelihara manusia
  • Saya juga sedang mengerjakan Postgres multithreaded. Dalam 1 bulan sudah lolos 96% pg regression test, dan ukurannya mencapai 823K LOC
    Semua itu tanpa Mythos, hanya dengan 8 akun Codex seharga $200 per bulan
    Saya juga melihat keunggulan Rust di sini, dan berdasarkan pengalaman dengan Postgres, saya rasa saya bisa mengambil keputusan desain yang baik di sejumlah bagian yang selama ini memang menyulitkan orang di pg. Menarik melihat bagaimana AI membuat perbaikan pada perangkat lunak kompleks yang dulu tidak praktis menjadi lebih mungkin dilakukan
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Ketika Microsoft menulis ulang ini ke Go, salah satu lead-nya menyebut kemiripan paradigma sebagai alasan memilih Go ketimbang Rust. Katanya hal-hal seperti garbage collection lebih mirip, dan Rust akan jauh lebih sulit serta butuh banyak workaround; saya penasaran bagaimana menurut orang yang benar-benar sudah mencobanya
  • Rust memang hebat, tetapi saat mencoba membangun perangkat lunak Rust skala besar bersama model bahasa besar, cara kerja yang diinginkan mulai runtuh
    Bahkan menjaga atau membangun boundary yang bersih pun tidak lagi terasa seperti kondisi fokus, melainkan review menyakitkan, dan akhirnya masuk mode menunda-nunda
  • Saya cukup kesulitan membuat Opus tidak mengabaikan idiom Rust dan tidak menulis Rust seaneh mungkin. Ada tips?

• Ini bukan pendapat yang sangat berbasis bukti, tetapi saya sudah tidak ingin terlibat dengan Bun lagi. Lebih dekat ke intuisi, tapi saya tidak bisa lagi percaya atau mendukungnya
  Mereka mem-fork Zig untuk memanfaatkan penulisan ulang dengan LLM, dan membuat hal-hal seperti kompilasi non-deterministik yang jelas-jelas tidak disukai tim Zig
  Sekarang mereka seperti merajuk sambil melakukan penulisan ulang dengan LLM ke Rust. Bisa jadi justru karena filosofi desain Zig memaksa keputusan yang sulit namun tepat, Bun bisa sampai ke posisi sekarang, dan penulisan ulang ke Rust benar-benar bisa menjadi awal kemunduran
  Ini lebih merupakan penilaian politik daripada teknis, tetapi Bun terlihat sepenuhnya ditopang Claude. Saya tidak akan kaget kalau slogan pemasaran Anthropic berikutnya adalah “Claude Mythos menulis ulang runtime JS 950K LOC terdepan ke Rust”

  • Saya tidak tahu apakah yang seperti bayi merengek itu adalah developer yang menulis kode di repositorinya sendiri, atau orang yang mengeluh soal itu di Hacker News
  • Saya tidak melihat Jarred merengek, jadi rasanya emosi itu salah sasaran
    Thread Twitter yang ditautkan justru memberi alasan teknis yang jelas
  • Saya pribadi tidak terlalu terikat dengan Bun, tapi saya tidak paham kenapa ini penting. Saya penasaran apakah dependensi lain juga ditinjau sedetail ini
    Bekerja di ekosistem JS/NPM sejak awal memang sangat bergantung pada kepercayaan murni terhadap dependensi yang tidak tervalidasi, dan sebelum atau sesudah penulisan ulang dengan LLM rasanya tidak banyak beda. Kalau tujuan awal dan kontrak API tetap terpenuhi, apa bedanya? Saya juga ragu apakah orang memang membaca source code yang lama dengan teliti
  • Setuju. Sejak awal Bun memang punya filosofi desain yang jelas. Mereka ingin melakukan semuanya sekaligus: runtime, bundler, test suite, package manager, lalu merilis patch yang rusak tiap minggu
    Setiap kali narasinya adalah melampaui pesaing lama dengan lebih baik, lebih cepat, lebih kuat, tetapi sangat jelas mereka sama sekali tidak akan pernah menjalankan Keep It Simple Stupid
    Juga jelas bahwa dalam waktu dekat, satu-satunya tempat yang akan benar-benar memakainya di produksi adalah startup YC yang terbakar satu per satu seperti disiram akseleran. Sekarang rasanya mereka sudah melewati titik tanpa balik
  • Bun pada dasarnya sudah mati
    Anthropic membeli Bun dalam upaya yang agak bodoh untuk menyelesaikan masalah “performa” mereka. Tampaknya mereka tidak sadar bahwa masalahnya sejak awal adalah kode yang buruk
    Meski begitu, mereka memang merekrut developer yang benar-benar kompeten, jadi mungkin ada sedikit manfaatnya
    Tetapi dalam prosesnya, Bun berubah dari proyek publik menjadi sesuatu yang lebih mirip alat internal Anthropic, dan sekarang cukup kehilangan fokus karena terlalu dimanja dana AI
    Saya cuma berharap saat gelembung itu pecah, setidaknya sebagian usaha yang dicurahkan ke Bun masih bisa diselamatkan. Saya tidak yakin Anthropic akan memeliharanya dalam jangka panjang. Mereka bukan perusahaan yang menjual dukungan runtime, dan juga tidak sebesar Google sampai bisa memelihara runtime di samping bisnis utamanya

• Kalau keterlibatan AI disisihkan sebentar, menurut saya ini perubahan yang bagus
  Saat memakai Zig, Bun punya crash dan bug memori yang sangat banyak, tidak seperti Deno yang berbasis Rust
  Tentu saja kalau port Rust Bun penuh unsafe, semua itu tidak akan otomatis hilang, tapi tetap kemungkinan akan membaik

  • Saya penasaran apakah ada statistik atau sumber untuk klaim bahwa Bun punya sangat banyak crash dan bug memori. Bukan berarti saya pikir itu salah
    Fakta bahwa bagian jelek jadi lebih terlihat lewat unsafe, sehingga mendorong refactoring, mungkin juga bukan murni soal bahasanya; ada kemungkinan Bun sendiri turut menyebabkan situasi itu
  • Apakah ini berarti Anda mengklaim memakai Zig membuat “crash dan bug memori jauh lebih banyak”?
    Kalau iya, bukankah itu berarti membuat perangkat lunak berkualitas tinggi dengan alat seperti itu pada dasarnya mustahil? Banyak hal berkualitas juga dibuat dengan C/C++, jadi saya penasaran apa yang sebenarnya salah pada Zig
  • Karena unsafe ditandai dengan jelas, jadi lebih mudah ditemukan, dan secara alami muncul daftar masalah yang harus diperbaiki

• Ini memakan waktu 6 hari. Bahkan kalau akhirnya tidak menghasilkan sesuatu yang bermakna, ini tetap menunjukkan bagaimana token dan jumlah kerja terhubung saat ini dan ke depan
  Akan makin sulit bersaing dengan individu atau perusahaan yang punya sumber daya komputasi lebih besar. Mereka akan bisa begitu saja melakukan hal-hal yang saya tidak bisa lakukan

  • Sudah dikenal luas bahwa menerjemahkan proyek dari satu bahasa ke bahasa lain, selama ada test suite yang bagus, adalah salah satu contoh terbaik dari hal yang sangat dikuasai model bahasa besar
    Kalau ada codebase yang sudah jadi untuk dijadikan contoh dan test suite untuk validasi, jauh lebih mudah untuk beriterasi menuju target yang diinginkan. Model sudah bisa melihat apa targetnya, dan seperti apa satu implementasi yang sudah ada, jadi masalahnya jauh lebih mudah daripada memulai dari spesifikasi
  • Hal yang sama bisa dikatakan tentang tenaga uap atau listrik. Dan ini bukan cuma analogi kosong. Keajaiban dari hal-hal ini adalah bahwa mereka merupakan mesin informasi serbaguna
    Anda menanamkan modal, membuatnya dengan teknik yang terukur dan dipahami dengan baik, colokkan listrik, lalu nilai pun keluar
    Intinya, tidak ada alasan bahwa ini harus menciptakan kelompok “punya” dan “tidak punya”, sama seperti listrik akhirnya tidak seperti itu di dunia modern
  • Tidak jelas juga. Produk yang sangat bagus biasanya lahir karena melakukan satu atau dua hal dengan sangat baik, bukan karena melakukan banyak hal
    Sejauh ini yang terlihat adalah “wow, sekarang saya jadi engineer 10x!” lalu orang mengeluarkan lebih banyak kode tanpa arah dan selera yang jelas. Sebagian besar kerja berbasis model bahasa besar saat ini tampak seperti kebisingan belaka
  • Tidak juga. Menjalankan agen-agen ini secara lokal makin mudah
    Entah Anda sudah mencoba Qwen 3.6 27b atau belum, tapi kemampuan model itu benar-benar gila untuk ukurannya. Kalau manajemen konteksnya bagus, proyek kecil bahkan bisa 100% vibe coding
    Model-model seperti ini pada akhirnya juga akan turun menjadi persaingan harga seperti komputasi
  • Saya penasaran kalau ini dibayar dengan tarif standar Anthropic, kira-kira habis berapa dolar ya. Ada yang bisa memperkirakan setidaknya secara kasar?

• Banyak orang menerima ini apa adanya, padahal sebagian besar hal ini dimungkinkan oleh test suite yang sangat luas dan komprehensif, jauh di atas standar yang telah dibangun sebelumnya

  • Tetap mengesankan, karena bahkan engineer paling kompeten pun mungkin akan butuh waktu jauh lebih lama untuk mencapai hal yang sama
    Saat nanti ini dipasarkan, akan bagus kalau mereka juga menuliskan berapa banyak upaya manusia yang dibutuhkan untuk merancang dan mengkurasi test suite yang memungkinkan kecepatan seperti ini
    Test suite bekerja hampir seperti lingkungan ideal bagi model bahasa besar generasi sekarang. Test suite yang cukup komprehensif menjadi spesifikasi yang memungkinkan agen mengimplementasikan sesuatu sesuai cara yang diinginkan, dan di sini targetnya adalah Rust
    Untuk proyek dengan pengujian sebaik Bun, saya bahkan merasa dalam beberapa kasus kita bisa membuang seluruh source code aslinya, hanya memberi akses ke test, dan tetap menulis ulang keseluruhan dari nol
  • Kalau test suite ini memang begitu “di atas standar” sampai menjadi hal yang secara unik memungkinkan pekerjaan ini dibanding proyek lain, saya jadi bertanya-tanya bagaimana itu bisa selaras dengan klaim bahwa Bun jauh lebih tidak stabil daripada program Zig lain sehingga perlu ditulis ulang
    Kalau sebagian tanggung jawabnya juga ada pada test suite, saya penasaran implikasinya bagi port Rust
  • Jadi yang harus kita lihat hanya fakta bahwa ini bisa dilakukan dalam 6 hari
    Dan kita harus mengabaikan ratusan ribu jam yang masuk ke arsitektur asli dan test suite yang membuatnya mungkin?

• Ini layak dilihat sebagai kisah peringatan untuk porting Rust yang menggunakan AI
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Lolos test tidak otomatis berarti benar-benar berfungsi
    Compiler C Claude code lulus 100% test gcc, tetapi bahkan tidak bisa menjalankan hello world
  • Pelajaran dari contoh-contoh itu agak berbeda. Model bahasa besar membangun sesuatu berdasarkan loop umpan balik yang Anda berikan
    Kalau Anda hanya memberi test logika, model sama sekali tidak akan memikirkan kecepatan. Kalau Anda memasukkan test yang mengukur kecepatan dan menyuruhnya memenuhi performa itu, maka itu juga akan dikerjakannya
    Ini jenis kesalahan yang sama dengan kesalahan model bahasa besar lainnya. Mereka tidak punya konteks akal sehat tentang hal-hal yang dianggap penting oleh manusia. Kalau boundary tidak dipaksakan, itu akan diabaikan
  • Kalau tertarik, ini pernah dibahas di sini: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - Maret 2026, 422 komentar

• Benar-benar zaman yang luar biasa untuk hidup
  Dinamika fundamental industri dan profesi ini berubah dalam waktu yang sangat singkat, nyaris dalam semalam
  Di hari tertentu saya bersemangat karena sekarang ada begitu banyak hal yang bisa saya lakukan; hampir apa pun yang saya inginkan bisa dibuat nyaris seketika, dan 100% dari hal-hal yang dulu saya impikan dengan perangkat lunak bisa menjadi nyata
  Di hari lain saya takut memikirkan apa yang akan terjadi pada pasar kerja
  Tiba-tiba kita bisa mendapatkan sangat banyak dari sangat sedikit, sementara jumlah perangkat lunak yang dibutuhkan dunia ada batasnya
  Apakah semua perusahaan yang model bisnis intinya menjual perangkat lunak akan bangkrut?
  Bagaimana kalau hanya perusahaan atau pemerintah tertentu yang punya akses ke model terbaik?

  • Coba pikirkan bisnis perangkat lunak seperti sistem ticketing
    Bisakah 100 perusahaan yang punya 1 miliar token membuat produk yang lebih baik daripada vendor spesialis yang punya 100 miliar token?
    Vendor perangkat lunak dan SaaS seperti “pembuat logo” memang pada dasarnya sudah mati, tetapi vendor sistem ticketing akan baik-baik saja kecuali sistem ticketing tertanam langsung di model bahasa besar generasi berikutnya. Jumlah pegawai mungkin akan turun, tapi belum tentu juga
  • Di sekitar masa pecahnya gelembung dot-com, cukup sering ada narasi di industri perangkat lunak yang berkata bidang ini sudah “terlalu jenuh” dan mahasiswa maupun pencari kerja sebaiknya tidak masuk
    Intinya, dibanding jumlah orang yang berdatangan, pekerjaan yang bisa dibagi tidak banyak, dan kejatuhan itu memperkuat narasi tersebut
    Tetapi bahkan sebagai mahasiswa saat itu, saya bisa melihat bahwa cakupan perangkat lunak pada dasarnya tak terbatas. Hampir semua pekerjaan kognitif yang sekarang kita lakukan secara manual bisa dikerjakan perangkat lunak. Saya pernah mencoba membuat daftar hal-hal itu, lalu cepat sadar bahwa jumlahnya terlalu banyak
    Selain itu, saya juga paham bahwa setiap kali kita melakukan pekerjaan dengan cara baru, akan muncul lebih banyak pekerjaan lain yang sebelumnya tidak pernah terbayangkan. Kemungkinannya tak terhitung, dan narasi “jenuh” itu jelas lahir dari kurangnya imajinasi dan pemahaman tentang apa itu perangkat lunak
    Karena itu saya tahu bidang ini tidak akan pernah jenuh. Mustahil kehabisan hal untuk dibuat dengan perangkat lunak
    Tetapi sekarang rasanya berbeda. Kita akan terus membuat perangkat lunak baru, tetapi kini saya bertanya-tanya apakah kecepatan kita menulis perangkat lunak akhirnya akan melampaui kecepatan kita membayangkan pekerjaan baru untuk dilakukan
  • Perusahaan dan pemerintah akan punya akses ke model yang lebih baik daripada publik. Mythos sebenarnya sudah menjadi contoh itu
    Publik tetap bisa membantu dirinya sendiri dengan model yang tertinggal dari garis depan

• Setidaknya menarik melihat upaya seperti ini berlangsung
  Hal pertama yang membuat saya penasaran adalah seberapa komprehensif dan berkualitas test suite-nya sejak awal. Bukan mau mencari-cari cela, tetapi meski 100% tercapai di semua platform, saya penasaran seberapa yakin tim Bun terhadap migrasi ini

• Setelah urusan Ubuntu coreutils minggu lalu, kesan saya terhadap penulisan ulang Rust dengan kompatibilitas test 99,8% benar-benar memburuk
  Saat saya klik tweet yang ditautkan di sini rasanya ngeri, dan sekarang setiap melihat hal seperti ini saya justru merasakan emosi yang sepenuhnya berlawanan. Rasanya seperti menemukan jalan keluar