Penulisan Ulang Rust Bun: "Codebase gagal pada pemeriksaan miri dasar dan mengizinkan UB di safe Rust"

• Isu ini saat ini berstatus Open, dan diskusinya dikunci sebagai off topic serta dibatasi untuk collaborator, dengan perbaikan terkait #30728 dan #30876 ditautkan
• Pelapor menunjukkan bahwa nilai yang dibuat dengan PathString::init masih bisa memanggil slice() setelah Box asalnya di-drop, sehingga Miri melaporkan Undefined Behavior berbasis dangling reference
• Kode reproduksi berbentuk meneruskan buffer yang dibuat dengan Box::new(*b"Hello World") ke PathString::init(&*test), lalu memanggil init.slice() setelah drop(test), dan Miri mengeluarkan error di titik core::slice::from_raw_parts
• robobun mengonfirmasi bahwa masalahnya dapat direproduksi, dan merangkum bahwa meskipun PathString::init adalah fungsi safe, fungsi itu menghapus slice lifetime sehingga dapat membuat &[u8] yang dangling
• #30728 yang ditautkan mengarah pada mengubah celah paralel di PathString::init dan dir_iterator::next() menjadi unsafe fn, serta menambahkan komentar SAFETY yang secara eksplisit menyebut backing allocation di sekitar 70 call site
• Perubahan yang sama juga dijelaskan mencakup compile_fail doctest yang memaksa kebutuhan kata kunci unsafe pada tiga signature, serta perbaikan kebocoran fd readdir-error di resolver
• AwesomeQubic menambahkan bahwa PathString::init juga menghapus provenance dan gagal pula di bawah MIRIFLAGS=-Zmiri-strict-provenance
• JavaDerg menjelaskan bahwa init menerima lifetime implisit dari &[u8], lalu menghapusnya melalui operasi unsafe dan mengembalikan Self yang terlihat seperti 'static, sehingga mengizinkan use-after-free dan invalid aliasing
• JavaDerg memperingatkan bahwa di atas model keamanan Rust, UB bisa menimbulkan masalah di lokasi yang tak terduga, sehingga penggunaan unsafe secara menyeluruh perlu ditinjau, dan menerjemahkan cara pengelolaan memori dari bahasa lain ke Rust secara 1:1 bukan pendekatan yang tepat
• robobun menambahkan commit terkait PathString::init signature stays unsafe test dan dir_iterator: make next() unsafe; audit call sites
• SimonReiff menunjukkan bahwa hasil grep unsafe di file Rust repositori, tidak termasuk komentar, mencapai 13255 baris, dan menuntut rollback segera serta pembahasan kebijakan dan prosedur penggunaan kode AI
• Jarred-Sumner menyatakan bahwa Rust port saat ini memulai dari 1:1 mapping yang sedekat mungkin dengan kode Zig asli dan sedang terus diperbaiki, serta meminta agar bug atau perilaku unsound di kode Rust terus dilaporkan sebagai isu baru

[GN⁺]

Komentar Hacker News

• Saya pertama kali tertarik pada Bun karena ditulis dengan Zig, dan saya tertarik pada Zig karena saya percaya pada keputusan dan selera Andrew Kelley
  Setelah itu, alasan-alasan lain yang membuat saya makin tertarik pada Bun juga pada akhirnya karena pilihan-pilihan yang menurut saya patut dihormati, jadi bahkan setelah akuisisi Anthropic saya tetap mencoba bersikap optimistis dengan hati-hati
  Tapi langkah kali ini terlihat seperti keputusan yang sulit dipercaya; masalahnya bukan pada Rust itu sendiri, melainkan jika Anthropic mengelola Bun dengan cara seperti ini, rasanya sulit lagi untuk bertaruh padanya sebagai komponen tepercaya dalam kotak peralatan
  Bukan cuma kodenya yang harus dipercaya, tapi juga cara berpikir di baliknya, dan sekarang ini terlihat seperti alat khusus internal Anthropic

  • Bun memang proyek yang sangat menarik, tetapi jumlah segmentation fault yang muncul di issue selama ini terlalu mengkhawatirkan untuk dipakai di lingkungan operasional yang serius
    Arah kali ini mungkin salah satu cara untuk memperbaikinya, jadi layak dipantau
  • Saya paham, tetapi titik berangkat saya cukup berbeda
    Sebagai penggemar lama Deno, Bun terlihat seperti Deno yang kurang ambisius, dan karena saya tidak ingin belajar Zig, kecil kemungkinan saya akan mengutak-atik Bun sendiri bahkan sebagai hobi
    Namun, selama beberapa tahun terakhir saya mencoba memelihara codebase TypeScript yang cukup besar dengan cara yang tidak terlalu terikat pada runtime, dan karena itu saya makin terbuka pada Bun; saya tidak ingin menjadikan runtime TypeScript tertentu sebagai persyaratan, tetapi Bun terus menawarkan alasan seperti Deno: Postgres, SQLite, S3, WebSocket, penyimpanan rahasia lokal, bundling, kompilasi, dan kecepatan tinggi
    Sekarang saya membuat beberapa server API dan server aplikasi frontend menjadi single executable bun build --compile --bytecode lalu menjalankan dan menerapkannya hampir di mana saja
    Meski begitu, saya tidak menganggap pendekatan ini umum, dan jika porting berbasis LLM kali ini gagal, saya berada di posisi yang sangat pas untuk menyesali semua keputusan terkait Bun
    Namun kalau tidak gagal, ini menarik. Ini akan jadi contoh yang menunjukkan apa yang mungkin dilakukan dengan LLM, dan ke depannya Bun dikembangkan dalam Rust adalah nilai plus bagi saya
    Sebaliknya, kalau gagal pun tetap penting sebagai informasi. Bun adalah salah satu runtime TS/JS utama, dan Anthropic punya sumber daya besar, akses ke model terbaru, dan anggaran yang nyaris tak terbatas, jadi kalau mereka pun tidak bisa, itu hampir berarti hal ini memang belum benar-benar mungkin dilakukan
  • Saya penasaran kenapa Bun lebih menarik bagi Anda daripada Deno

• Kalau memang mau memindahkan Zig ke Rust yang tidak aman, saya tidak paham kenapa mereka tidak membuat alat translasi
  Mereka seharusnya bisa mendapatkan transformasi yang deterministik dengan memetakan konstruksi bahasa satu per satu dan meng-hardcode pola-pola dalam codebase; seperti kata teman saya, bahkan pendekatan seperti “menghubungkan zig translate-c ke c2rust” pun mungkin saja
  Hasilnya sekarang malah terasa kurang bisa dipercaya daripada input-nya. Input-nya memang tidak aman terhadap memori, tetapi ditulis langsung oleh manusia; output-nya bukan hanya tidak aman terhadap memori, tetapi juga hasil vibe coding dan tampaknya belum pernah benar-benar diperiksa manusia
  Saya tidak paham apa gunanya menyalahgunakan AI agen untuk keperluan seperti ini

  • Kalau pernah melihat hasil c2rust, sulit untuk berkata begitu
    Pendekatannya meniru semantik pointer C yang tidak aman dengan pustaka fungsi Rust yang tidak aman, jadi hasilnya mengerikan
    Beberapa tahun lalu saat melihat bug OpenJPEG, ada yang mencoba mengonversinya dengan c2rust, dan Rust tidak aman hasil konversi itu tetap menghasilkan segmentation fault di titik yang sama seperti kode C aslinya
    Kompatibel, ya, tapi tidak aman
    Intinya, manipulasi string jangan dilakukan dengan C atau Rust tidak aman. Itu alat yang sama sekali tidak cocok untuk pekerjaan tersebut
  • Mereka memang membuatnya. Alat translasi yang sangat dinamis
  • “Tinggal hubungkan zig translate-c ke c2rust” tidak bekerja semudah yang dibayangkan
    Alat-alat seperti ini banyak salahnya dan membuat kode jadi sangat bertele-tele serta sulit dipahami
    Mungkin cocok untuk aplikasi kecil, tetapi tidak cocok untuk penulisan ulang secara menyeluruh
  • Saya juga mengatakan hal yang hampir sama di thread lain, tetapi saya punya sudut pandang yang sedikit berbeda soal cara menulis perangkat lunak
    Daripada menerjemahkan Zig ke Rust, menurut saya lebih baik menulis parser JPEG dalam Python statis, lalu menurunkannya ke Zig dan Rust dengan struktur idiomatis yang sesuai untuk masing-masing bahasa
    Untuk itu saya membuat parser dialek Python yang cocok untuk tujuan ini, dan ingin mengadopsi beberapa fitur Rust/Zig yang memudahkan translasi sambil tetap menjaga kompatibilitas dengan sebagian besar kode Python
    Parser JPEG juga disertakan sebagai aset contoh
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • Cara yang benar untuk mem-porting codebase ke bahasa lain adalah dengan mem-parsing syntax tree lalu menerapkan transformasi yang deterministik dan tervalidasi

• Issue ini menimbulkan salah paham
  Masalahnya bukan sekadar adanya undefined behavior yang bisa ditangkap miri, melainkan bahwa mereka mengekspos API yang bisa memicu undefined behavior dari kode aman. miri pun hanya bisa menangkapnya jika ada tes yang ditulis untuk membuktikan itu
  Hal seperti ini saat melakukan porting awal dari bahasa yang tidak aman tidak sepenuhnya tidak masuk akal
  Tim Bun juga tampaknya kemudian memeriksa apakah fungsi-fungsi pembungkus untuk kode tidak aman itu sudah benar
  Menandai sebagian fungsi tidak aman sebagai aman untuk sementara selama tahap porting bukan masalah besar dengan sendirinya, tetapi menggabungkannya ke repositori utama dalam keadaan seperti itu memang agak aneh
  Masalah sebenarnya adalah jika kode dalam kondisi ini dirilis
  Yang disayangkan adalah mereka tidak langsung menyiapkan agar tes dijalankan dengan miri. Soalnya LLM merespons dengan baik terhadap tes yang bagus
  Saya menilai begitu bukan karena issue GitHub ini, melainkan karena tes lain [1] benar-benar memanggil undefined behavior yang akan ditangkap miri. Namun tampaknya kode yang diuji itu tidak dipakai di mana pun, jadi dampak nyatanya mungkin tidak besar
  Ini masih tahap awal porting, jadi mungkin nanti akan diperbaiki, dan mungkin juga kode tidak aman yang sebenarnya tidak diperlukan akan dihapus
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - pointer-pointer yang diturunkan dari referensi mutable pertama menjadi tidak valid ketika referensi mutable baru dibuat ke objek yang sama. Dalam istilah gaya C, anggap saja “referensi mutable” sebagai “referensi restrict tempat perubahan sepele dilakukan”
  Cara yang benar adalah menurunkan semua pointer dari referensi mutable yang sama, tetapi mereka tidak melakukannya
  Kalau orang-orang berbondong-bondong ke GitHub untuk membanjiri issue, kemungkinan orang mau bekerja secara terbuka justru makin kecil. Sebaiknya jangan begitu
  Dan lebih baik menahan penilaian sampai kondisinya sudah layak dipublikasikan. Menilai status kerja yang masih setengah jalan itu tidak adil, juga tidak terlalu menarik

  • Begitu sebuah proyek mencapai 1.0, banyak orang berharap branch main selalu berfungsi
    Ini karena CI/CD pada akhirnya mendekati asumsi bahwa setiap commit harus berjalan
    Kode yang masih dalam pengerjaan dan belum berfungsi, seperti penulisan ulang total, seharusnya dikerjakan di branch
    Dengan begitu main tetap berfungsi ketika sesuatu seperti perbaikan keamanan diperlukan

• Hasil seperti ini tidak mengejutkan karena cara yang diminta memang hampir berupa porting literal
  Bisa juga dilihat bahwa lebih baik memindahkan Bun terlebih dahulu ke bahasa dengan sistem tipe yang lebih kuat, lalu menggunakan sistem tipe itu sebagai pijakan untuk perbaikan lanjutan
  Kelihatannya lebih masuk akal daripada menuntut kesempurnaan sejak langkah pertama

  • Sebenarnya itulah yang mereka lakukan
    Mereka sedang menangani issue yang masuk
  • Tinggal tambahkan “jangan ada undefined behavior” ke prompt, nanti beres
  • Sekarang sepertinya kita bisa menekan penulisan ulang ini dengan alat seperti miri, lalu membiarkan Claude Code memperbaikinya secara otomatis
  • Undefined behavior pada kode Rust yang sebagian besar hasil translasi literal, dengan sebagian kode tidak aman, bukan hal yang mengejutkan
    Yang mengecewakan adalah API kode Rust itu dapat memicu undefined behavior padahal tidak ditandai sebagai unsafe
    Kalau saya yang melakukan translasi seperti ini, saya akan konservatif dan menandai semuanya atau sebagian besar sebagai unsafe pada awalnya
    Lalu keamanan tiap bagian bisa diverifikasi secara bertahap

• Jujur saja, saya agak terkejut mendengar mereka bilang semuanya sudah benar-benar berjalan hanya dalam seminggu
  Proyek sampingan saya https://tsz.dev punya ambisi serupa, tetapi saya jelas belum bisa mengklaim berhasil
  Saya terus menambahkan tes untuk memastikan perilakunya, dan bahkan setelah lulus semua tes milik TypeScript sendiri pun saya masih menemukan bug seperti yang sudah diduga
  Standar untuk menyamakan perilaku dengan tsc itu memang sangat sangat tinggi
  https://github.com/type-challenges/type-challenges
  Saya tidak menentang penulisan banyak kode dengan LLM, tetapi sekarang ketika kode bisa dikeluarkan secepat ini, verifikasinya harus 100 kali lebih kuat

  • Yang mengejutkan adalah mereka menggabungkan codebase skala sejuta baris dari sebuah “eksperimen” hanya dalam seminggu, yang kemungkinan besar hampir tidak ditinjau sama sekali
    Saya tidak menentang penggunaan agen, tetapi terburu-buru melakukan hal seperti ini dan mendadak mengejutkan komunitas terlihat sangat amatir
    Ini perilaku yang lebih cocok diharapkan dari insinyur baru yang terlalu bersemangat
  • https://tsz.dev/sound-mode/
    Ini luar biasa. TypeScript butuh lebih banyak hal seperti ini, dan semoga makin dikenal hingga Microsoft mau mengadopsinya
    Hanya saja, saya rasa perlu hati-hati menyebutnya sound mode
    Kalimat “ini bukan bukti soundness dalam makna matematis, dan tidak membuat file .d.ts pihak ketiga menjadi benar” mencampurkan dua hal yang sama sekali berbeda
    Pertama, soundness adalah konsep matematis. Jika sesuatu sound, maka ia benar-benar sound, dan itu berarti kita bisa mempercayai compiler tanpa harus memeriksa detailnya secara manual
    Kalau ada bug implementasi, hasilnya bisa salah, tetapi itu bisa diperbaiki; sedangkan soundness berarti tidak ada cacat teoretis pada spesifikasi atau sistem tipenya sendiri
    Kedua, sangat wajar dan bisa diduga bahwa bahasa di dunia nyata membutuhkan fitur tak diperiksa yang diasumsikan dipakai dengan benar oleh manusia. Contohnya seperti unsafeCoerce di Haskell atau sun.misc.unsafe di Java
    Masalah yang sebenarnya adalah jika sistem tipe rusak bahkan ketika fitur-fitur seperti itu tidak dipakai
  • Menyebutnya sudah berjalan rasanya agak berlebihan
    Saya baru melihat kodenya beberapa menit, tetapi begitu optimisasi dinyalakan sepertinya semuanya akan rusak parah
  • Mereka mungkin sudah berbulan-bulan merencanakan dan bereksperimen dengan ini
    Dengan test suite besar yang sudah ada, ditambah alat untuk memparalelkan agen, dan anggaran token yang pada dasarnya tak terbatas, tidak perlu terlalu berkecil hati

• Ada sebuah buku yang sangat mengubah cara saya memandang perhatian dan media [0]
  Bukunya sendiri tidak terlalu bagus, tetapi ada poin yang relevan di sini
  Ada asimetri besar antara jangkauan pengumuman besar dan mencolok, misalnya pesan seperti “Bun ditulis ulang ke Rust yang aman terhadap memori hanya dalam beberapa minggu”, dan jangkauan koreksi, misalnya catatan kaki di artikel lama atau issue GitHub
  Asimetri ini dipahami dengan baik dan dimanfaatkan secara aktif oleh industri marketing dan PR
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Dari suasana kali ini, kelihatannya banyak orang berusaha mencari kritik apa pun terhadap kode ini lalu membesarkannya semaksimal mungkin
    Untuk saat ini sebagian besar terlihat cukup dangkal
    Menggabungkan porting besar dengan bantuan LLM jelas keputusan yang sangat berani, tetapi dari apa yang ditunjukkan orang-orang tentang hasil nyatanya, saya tidak melihat banyak hal yang terasa lebih buruk daripada porting lain yang masih berlangsung
    Setiap issue yang ditemukan dibesar-besarkan secara berlebihan
  • Saya malah ragu apakah mereka benar-benar mengklaim ini aman terhadap memori
    Di semua diskusi tentang topik ini, ada puluhan komentar yang mengatakan codebase hasil vibe coding itu pasti penuh blok unsafe yang belum diaudit, dan ditinjau secara asal oleh orang-orang yang tampaknya tidak memahami Rust
    Bahkan terlihat seperti mereka marah pada gagasan bahwa bahasa pemrograman apa pun memang harus dipahami
  • Saya jadi teringat kutipan “kebohongan sudah mengelilingi separuh dunia sebelum kebenaran sempat memakai sepatu”, mungkin maksudnya konsep ini
  • Bukan hanya marketing dan PR; media arus utama juga tahu bahwa kalau mereka lebih dulu menerbitkan omong kosong lalu menariknya belakangan, efeknya tetap bertahan
    Orang biasanya ingat artikel atau judul awalnya, tetapi tidak pernah melihat koreksinya
  • Saya justru mengira Anda akan membicarakan masalah ke arah sebaliknya
    Porting ini masih berlangsung, jadi belum ada pengumuman besar dan mencolok, dan juga belum selesai atau dirilis
    Pengumuman mencolok yang saya lihat justru berupa ejekan model hit-and-run terhadap kode yang masih dikerjakan, serta upaya menyiratkan seolah timnya pernah mengatakan bahwa semuanya sudah selesai atau sempurna
    Penulisan ulang ini adalah translasi kode untuk dijadikan titik awal
    Tim Bun tidak pernah membuat pengumuman besar bahwa kodenya sekarang aman terhadap memori, dan mereka sudah jelas mengatakan bahwa ini titik awal
    Jadi berharap semuanya langsung sempurna dan semua masalah memori dari kode Zig asli langsung terselesaikan berarti berdebat melawan pengumuman imajiner, bukan pengumuman nyata dari tim Bun
    Saya juga penasaran apakah ada yang sudah memetakan apakah masalah memori ini juga ada di codebase aslinya

• Jenis kesalahan seperti ini sudah bisa diperkirakan
  Demi orang-orang yang membutuhkan kestabilan, versi stabil tetap dibiarkan dalam Zig, dan pada akhirnya saya yakin kesalahan-kesalahan ini akan diperbaiki

  • Kesalahan seperti ini sebenarnya cukup bisa dihindari
    Ekosistem Rust punya alat-alat terkenal untuk menangkap kesalahan seperti ini, dan meskipun tidak akan menangkap semua undefined behavior yang muncul karena kesalahan blok unsafe, menjalankannya tetap dianggap praktik yang baik

• Yang paling saya khawatirkan adalah percakapan meta
  Awalnya saya cukup kritis terhadap para maintainer yang menutup issue GitHub ini sebagai di luar topik
  Namun, UI GitHub ternyata otomatis melipat sekaligus sekumpulan pesan yang sama sekali tidak punya nilai informasi, dan pesan-pesan itu tampaknya datang berbondong-bondong dari forum atau Discord komunitas
  Ini menempatkan semua orang dalam situasi kalah
  Seseorang yang menemukan masalah serius yang patut dikhawatirkan oleh banyak komunitas terkait punya alasan kuat untuk menyebarkannya seluas mungkin
  Ini adalah permintaan yang substantif terkait perubahan terbaru, dan masalah faktanya tidak hilang hanya karena nada bicara dipersoalkan
  Masalahnya, perhatian tambahan justru secara harfiah membunuh diskusi
  Di sisi maintainer, ini juga bisa menjadi tameng bagi orang yang membuat keputusan yang lebih emosional atau nyaris seperti psikosis AI
  Proyek dengan mentalitas terkepung yang memblokir dan mengabaikan kritik sangat mudah keluar jalur dengan cepat
  Sebaliknya, dalam proyek yang tidak mampu melindungi maintainer dari kecemasan dan patologisasi terkait AI, burnout maintainer menjadi hal yang tak terhindarkan

• Penulisan ulang Bun kali ini terasa seperti potensi acara untuk marketing Mythos

  • Sampai sekarang tidak ada seorang pun dari tim Bun atau Anthropic yang memasarkan hal ini secara berlebihan lebih dari sekadar menyebutnya sebagai perubahan ke bahasa yang lebih aman terhadap memori dengan jaminan compiler yang lebih baik
    Kehebohan dan promosi sejauh ini justru kebanyakan datang dari reaksi negatif orang-orang yang anti-AI
    Menurut saya, ini juga sangat bercampur dengan persepsi negatif yang makin besar terhadap Anthropic sendiri akibat beberapa keputusan Anthropic belakangan ini
  • Ini cuma terlihat seperti rug pull versi korporat
    Rasanya kebutuhan Anthropic adalah satu-satunya prioritas, dan hal lain tidak dipedulikan
  • Mereka menjalankan penulisan ulang ini dengan entah berapa banyak uang untuk token tak terbatas
    Lalu membuat heboh besar dan menulis posting blog dengan pesan “Claude Code memungkinkan tim Bun menulis ulang lebih dari sejuta baris Zig ke Rust” sehingga para VC meneteskan air liur
    Ternyata gagal pada pemeriksaan dasar
    Mythos dibiarkan merobek-robek codebase, entah menghabiskan berapa banyak uang lagi
    Mereka menulis posting blog terpisah lagi
    Para penipu dan orang-orang lugu bertepuk tangan sambil membelanya melawan “kerumunan anti-AI yang delusional”
    Para VC makin bergairah
    Beginilah cara menghasilkan uang
    Dan lalu arahnya menjadi bahwa insinyur perangkat lunak sekarang juga harus dihapus

• Saya tidak paham kenapa orang berasumsi bahwa codebase dari bahasa yang tidak aman, yang juga memiliki binding ke bahasa tidak aman lain, akan langsung tampak diimplementasikan dengan sempurna