Pendapat saya tentang penulisan ulang Bun ke Rust

 (en.liujiacai.net)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Penulisan ulang Bun ke Rust lebih dekat pada keputusan memindahkan arsitektur dan struktur data yang sudah ada yang dibuat dengan Zig ke stack teknologi yang lebih arus utama, sambil mempertahankannya
  • PR penulisan ulang itu berukuran 6.755 commit dan dibuka pada 8 Mei lalu digabung pada 14 Mei, sehingga menyisakan pertanyaan tentang kedalaman review untuk perubahan runtime kelas produksi
  • Lolosnya pengujian hanya memverifikasi jalur yang sudah diketahui, dan sulit menjamin hingga invarian global seperti jalur error, konkurensi, dan kondisi memori ekstrem
  • Intinya bukan kegagalan Zig, melainkan ketidakselarasan struktural antara budaya tim Bun yang mengutamakan rilis cepat dan biaya manajemen memori manual
  • Taruhan sebenarnya bukan Zig vs Rust, melainkan apakah kode yang dihasilkan AI dan tidak direview dengan memadai bisa dipelihara dalam jangka panjang

Fondasi Bun yang dibangun oleh Zig

  • Sebelum melihat PR penulisan ulang Bun ke Rust, peran Zig sangat besar dalam membawa Bun ke posisinya sekarang
  • Jarred memilih Zig bukan karena “terlihat keren”, melainkan karena Zig memungkinkan tim kecil membuat prototipe runtime JS berperforma tinggi tanpa garbage collector dengan cepat
  • Friksi rendah di Zig, manipulasi memori langsung, dan interoperabilitas C yang sederhana memungkinkan performa awal Bun dan ukuran tim yang kecil
  • Seperti yang dikatakan Jarred, “arsitektur tidak berubah, dan struktur datanya juga tidak berubah”, sehingga penulisan ulang ke Rust lebih dekat pada struktur yang mewarisi kerangka yang dibuat dengan Zig
  • Membangun fondasi dengan Zig, merilis produk, menggalang investasi, lalu setelah perusahaan diakuisisi dan membesar berpindah ke stack teknologi yang lebih arus utama bisa dilihat sebagai keputusan bisnis yang normal
  • Namun, sulit membingkainya sebagai bukti bahwa Zig itu sendiri tidak cocok

Risiko penulisan ulang besar yang digabung hanya dalam 6 hari

  • PR penulisan ulang mencatat 6.755 commit, nama branch claude/phase-a-port, dibuka pada 8 Mei dan digabung pada 14 Mei
  • Masalah utamanya adalah bahwa penulisan ulang penuh runtime JS kelas produksi itu digabung hanya dalam 6 hari
  • Prinsip dasar rekayasa perangkat lunak adalah “kode yang tidak dipahami tidak boleh dijalankan di produksi”
  • Prinsip ini penting bukan semata karena kode itu pasti punya bug, tetapi karena saat bug muncul, kita tidak tahu harus mulai memeriksa dari mana; ini menjadi garis dasar maintainability
  • Dalam daftar reviewer PR ada coderabbitai[bot] dan claude[bot], sementara satu-satunya reviewer manusia alii berstatus “Awaiting requested review”
  • Loop tertutup di mana Claude menulis dan Claude mereview memang tidak mustahil secara logis, tetapi pada akhirnya itu berarti tidak ada manusia yang benar-benar membaca seluruh codebase sampai tuntas

Apa yang tidak bisa dijamin oleh pengujian yang lolos

  • Sekalipun test suite lolos di semua platform, itu hanya memverifikasi kebenaran perilaku yang sudah diketahui dan jalur yang sudah diketahui
  • Test suite sulit memberi jaminan memadai pada area berikut
    • apakah jalur error ditangani dengan benar
    • bagaimana perilakunya pada kondisi batas dalam situasi stres
    • apakah konsistensi state tetap terjaga dalam kondisi konkurensi
    • apakah model memori sesuai dengan niat desain dalam kondisi ekstrem
  • Jarred juga diringkas mengakui bahwa masalah memori saat masuk kembali ke boundary JS tidak bisa ditangani oleh compiler Rust dan tetap bergantung pada manusia
  • Masalahnya adalah, bagian yang harus bergantung pada manusia itu tidak direview oleh manusia
  • Penerjemahan kode oleh AI lebih dekat pada kesetaraan semantik lokal: memastikan tiap fungsi berperilaku sama dengan aslinya dalam keadaan terisolasi
  • Invarian global antar fungsi, serta batasan desain yang tidak tertulis di pengujian dan hanya ada di kepala penulis asli, sulit dijamin hanya dengan translasi AI
  • Batasan seperti ini bisa saja tidak terlihat di pengujian saat ini, lalu muncul 6 bulan kemudian sebagai crash yang sulit dijelaskan pada beban produksi tertentu
  • Ini bukan masalah khusus Claude; hal yang sama berlaku untuk semua alat dan programmer manusia yang menerjemahkan tanpa review yang memadai
  • Pada skala 6.755 commit, risiko seperti ini membesar secara signifikan

Siapa yang menanggung risiko setelah akuisisi

  • Bun pada awalnya adalah proyek tempat Jarred bertaruh pada dirinya sendiri; penggunaan Zig, iterasi cepat, dan penerimaan technical debt bisa dilihat sebagai logika startup yang menanggung risiko sendiri
  • Kini setelah Bun diakuisisi oleh perusahaan besar dan memiliki basis pengguna yang memakainya di sistem produksi nyata, pihak yang menanggung risiko penulisan ulang bukan lagi Jarred melainkan insinyur yang menjalankan Bun di produksi dan para pengguna di belakang mereka
  • Jarred mengatakan versi tersebut masih canary, dan masih ada pekerjaan optimasi serta perapian sebelum rilis resmi
  • Canary adalah garis pertahanan, tetapi bukan pengganti review manusia
  • Optimasi dan perapian adalah persoalan kualitas kode; itu tidak menyelesaikan pertanyaan apakah para maintainer benar-benar memahami kodenya
  • Codebase yang tidak pernah dibaca sepenuhnya oleh siapa pun akan tetap menjadi kotak hitam bagi maintainer, meskipun pengujiannya komprehensif atau masa canary panjang
  • Masalah ini bisa muncul sebagai penderitaan nyata saat nanti harus melakukan debugging bug serius

Kekeliruan dalam mendiagnosis masalah Zig

  • Alasan yang sebelumnya diajukan Jarred adalah bahwa codebase Zig memiliki banyak use-after-free, double-free, dan kebocoran memori pada jalur error
  • Diagnosis ini sendiri benar, tetapi sulit menarik kesimpulan “Zig tidak bekerja” dari sana
  • Diagnosis yang lebih tepat adalah bahwa dalam proyek komersial yang mengutamakan iterasi cepat, biaya kognitif manajemen memori manual telah melampaui anggaran tim
  • Ini bisa dilihat bukan sebagai bug Zig, melainkan ketidakselarasan struktural antara tujuan desain Zig dan model bisnis Bun
  • Pengguna sasaran Zig adalah programmer sistem yang tahu apa yang mereka lakukan dan bersedia membayar biayanya demi kontrol akhir
  • TigerBeetle menulis database dengan Zig yang praktis hampir tanpa bug memori, dan ini diringkas karena budaya tim serta sifat proyeknya cocok dengan filosofi Zig
  • Budaya tim Bun lebih dekat pada iterasi cepat, rilis cepat, dan perbaikan bug cepat; ini secara mendasar berada dalam hubungan tegang dengan disiplin memori ketat yang dituntut Zig
  • Menafsirkan “tim kami sering melakukan kesalahan dengan alat ini” sebagai “alat ini tidak cocok” mendekati kesalahan atribusi
  • Digunakan analogi bahwa kalau palunya tidak cocok, itu tidak berarti palunya sendiri yang salah

Prospek jangka pendek dan risiko jangka panjang

  • Dalam jangka pendek, versi hasil penulisan ulang kemungkinan besar akan baik-baik saja
  • Jalur utama tercakup oleh pengujian, masalah yang jelas akan muncul pada tahap canary, dan jaminan compiler Rust menghilangkan satu jenis bug memori
  • Di permukaan, semuanya bisa tampak normal
  • Dalam jangka panjang, 6.755 commit yang belum pernah dibaca sepenuhnya oleh manusia tetap menjadi risiko struktural
  • Jika 6 bulan kemudian muncul bug konkurensi yang aneh, atau kondisi batas pada beban tertentu memicu perilaku ganjil, engineer yang melakukan debugging akan menghadapi sistem yang tidak pernah benar-benar dipahami siapa pun
  • Yang dimaksud dengan sistem yang belum pernah dipahami bukanlah bahwa sistem itu tanpa bug, melainkan bahwa ketika bug muncul, tidak ada yang tahu kenapa
  • Taruhan teknis yang sebenarnya dalam penulisan ulang ini bukan Zig vs Rust, melainkan apakah kode yang dihasilkan AI dan tidak direview bisa dipelihara dalam jangka panjang di lingkungan produksi
  • Pertanyaan ini lebih kompleks daripada “semua pengujian lolos”, dan lebih dalam daripada “keamanan memori Rust”
  • Kesimpulannya diringkas lewat analogi: “Zig membangun fondasinya, Claude mendirikan bangunannya, dan reviewer manusia masih dalam perjalanan”
  • Berapa lama bangunan ini tetap layak dihuni akan bergantung pada apakah seseorang bisa membaca cetak birunya saat kebocoran pertama muncul

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Lobste.rs

  • Sebelum membahas “menulis ulang Bun dalam Rust”, perlu dikatakan bahwa Bun bisa sampai di posisinya sekarang itu berkat Zig
    Pembuat Bun, Jarred, juga mengatakan hal yang sama. Katanya Zig memungkinkan Bun ada, dan Zig punya andil besar dalam pertumbuhan proyek yang awalnya dikoding sendirian selama setahun di kamar bau di Oakland itu menjadi salah satu alat yang paling luas dipakai di ekosistem JavaScript
    Ia juga mengatakan bahwa Zig adalah bahasa yang hebat dan Bun sangat berutang pada kesuksesannya, tetapi proyek lain seperti Ghostty atau Tigerbeetle tidak mengalami masalah stabilitas yang dialami Bun

    • Jika memang “proyek lain seperti Ghostty atau Tigerbeetle tidak mengalami masalah stabilitas yang dialami Bun”, pantas ditanya kenapa begitu
      Biasanya database punya tantangan stabilitas yang jauh lebih besar daripada runtime bahasa

  • Tulisan ini sangat terasa seperti ditulis oleh LLM

  • Jika pengguna sasaran Zig adalah “programmer sistem yang tahu apa yang mereka lakukan dan siap membayar harga demi kontrol tertinggi”, itu terlihat seperti rasa terlalu percaya diri ala C/C++ yang muncul lagi dalam konteks bahasa yang lahir setelah Rust dan Swift
    Jika alasan Jarred pindah adalah “terlalu banyak use-after-free, double free, dan kebocoran memori di jalur error dalam codebase Zig”, maka ini jadi satu titik data tentang apakah bahasa yang tidak memory-safe bisa dibuat praktis aman hanya dengan menyuruh LLM rajin mencari bug keamanan memori
    Bahkan perusahaan LLM sendiri tidak menempuh jalan itu di sini

  • Pernyataan “karena kodenya ditulis Claude dan direview Claude, loop tertutupnya tidak mustahil secara logis, tetapi itu berarti tidak ada manusia yang pernah benar-benar membaca seluruh codebase ini” tampak jelas tidak tepat
    Jika codebase Zig yang ditulis manusia diterjemahkan secara mekanis ke Rust, orang yang memahami kode aslinya juga bisa memahami kode barunya. Ini bukan dipindahkan ke APL; keduanya sama-sama bahasa prosedural dalam tradisi sintaks C
    Poin bahwa jika LLM dijalankan tanpa pengawasan ke depannya, kode bisa makin menjauh dari intuisi manusia, masih terbuka. Tetapi codebase saat ini tetap tampak dapat dipahami, setidaknya sejauh yang wajar untuk runtime JavaScript sejuta baris sekaligus alat serbabisa satu biner
    Kalimat “AI hanya mencocokkan kesetaraan semantik lokal di tingkat fungsi, dan tidak memahami invarian global antar-fungsi” terdengar aneh baik jika dibaca pro-LLM maupun anti-LLM
    LLM tidak cukup deterministik untuk menjamin bahwa setiap fungsi berperilaku identik dengan aslinya. Untuk jaminan seperti itu, dibutuhkan alat seperti c2rust. LLM bisa menerjemahkan kode yang tampak mirip dengan aslinya, tetapi yang mencegah ((abc & 45) << 3) == 360 berubah menjadi ((abc & 45) << 30) == 360 hanyalah compiler, test suite, dan mungkin deteksi probabilistik dari code review berbasis LLM
    Sebaliknya, jika ada penerjemah seperti c2rust yang menjamin kesetaraan tiap fungsi sekaligus mempertahankan komentar dan struktur seperti LLM, itu adalah penerjemah sempurna dan codebase sejuta baris pun bisa dipindahkan otomatis. Compiler juga bisa dilihat sebagai kasus khusus seperti ini, dan Clang, walaupun tidak bebas bug, cukup dekat untuk dipercaya orang. Jika LLM bisa menerjemahkan Zig atau C++ ke Rust dengan tingkat kepercayaan setara Clang, Chrome pasti sudah menjadi Rust murni pada akhir bulan ini
    Selain itu, mengenkode invarian antar-fungsi memang inti dari sistem tipe. Salah satu alasan Bun ditulis ulang ke Rust juga karena sistem tipe Rust lebih mampu mengekspresikan invarian kompleks. Anthropic juga bukan sampai mengompilasi semuanya ke assembly lalu membakar source code-nya

    • Kalimat “jika codebase Zig yang ditulis manusia diterjemahkan secara mekanis ke Rust, orang yang memahami kode aslinya juga bisa memahami kode barunya” rasanya akan dioptimalkan habis-habisan dalam release fast :^)
      Bun sudah lama dikoding dengan vibe coding bahkan jauh sebelum port Rust. Mereka cukup cepat mengadopsi AI, dan setelah akuisisi Anthropic hampir semua commit ditulis bot. Jarred juga pernah menulis tweet bahwa selama akhir pekan ia menyuruh AI menulis fitur dan berhasil menambahkan beberapa fitur
    • Terlepas dari poin Kristoff bahwa Bun sudah lama bukan codebase yang ditulis manusia, ini tampaknya mengasumsikan port oleh Claude adalah terjemahan mekanis, padahal kenyataannya sepertinya tidak begitu
      HTML Parsers in Portland menganalisis beberapa port parser HTML Python dan menunjukkan bahwa salah satu algoritma inti diimplementasikan sangat berbeda di tiap port. Di semua kasus itu, port mekanis sebenarnya memungkinkan, tetapi dalam praktiknya tidak dilakukan
      Tentu itu contoh dari awal tahun ini dan prosesnya juga berbeda, tetapi beberapa potongan yang saya lihat di codebase Bun pasca-port tampak mengalami masalah serupa
    • Pernyataan “jika codebase Zig yang ditulis manusia diterjemahkan secara mekanis ke Rust, orang yang memahami kode aslinya juga bisa memahami kode barunya” sendiri memang benar
      Tetapi fakta bahwa “LLM tidak cukup deterministik untuk menjamin bahwa setiap fungsi berperilaku identik dengan aslinya” pada akhirnya mengarah ke kesimpulan bahwa tidak ada manusia yang benar-benar membaca seluruh codebase ini

  • Satu contoh dari “semua tes lolos”: https://github.com/oven-sh/bun/…

    • Perubahan dalam commit itu tidak masuk ke diff final, dan itu pun mudah diketahui jika dicek langsung
      Melihat beberapa orang di forum lain juga menautkan commit yang sama, tampaknya mereka melihat tautan itu dari suatu tempat, merasa cocok dengan ekspektasi mereka, lalu tidak memeriksa apakah memang relevan. Menurut saya kita seharusnya menerapkan standar yang lebih tinggi pada diri sendiri
    • Suka atau tidak, commit itu adalah commit yang ditulis manusia yang sebagian membatalkan commit sebelumnya yang juga ditulis manusia
      Commit pertama: “await process exit / JSON-parse-retry instead of fixed sleeps”
      Revert: “test: revert proc.exited change in spawn.test.ts, keep isDebug iteration count”

  • Akhir-akhir ini saya banyak memikirkan prinsip “jangan jalankan kode di production kalau Anda tidak memahaminya”
    Karier saya sudah cukup jauh, tetapi saya sengaja tidak masuk jalur manajemen, dan perjalanan saya dalam pemrograman justru makin turun ke lapisan bawah stack. Itu karena saya suka benar-benar memahami program itu sendiri secara mendalam. Merilis fitur dan membuat hidup pengguna lebih baik juga sangat penting, tetapi salah satu ganjaran batin terbesar dalam pemrograman adalah perasaan belajar fakta yang benar tentang sistem nyata
    Bagi orang seperti saya, gagasan bahwa manusia harus memahami setiap baris program terasa seperti aksioma. Namun manajer saya di bagan organisasi bertanggung jawab atas program yang saya rawat. Ia manajer yang hebat dan tidak micromanage, sehingga tentu saja ia tidak memahami setiap baris perangkat lunak yang dirilis tim. Bahkan saya tidak yakin ia hampir pernah membaca kodenya. Kalau begitu, berarti ia melanggar prinsip ini
    Saya sedang memikirkan apakah ada perbedaan yang bermakna antara “kode yang ditulis bawahan saya dan tidak saya pahami” dan “kode yang ditulis AI saya dan tidak saya pahami”
    Yang pertama terasa oke, tetapi yang kedua terasa mengganggu. Apakah bedanya hanya ada atau tidaknya manusia yang bertanggung jawab atas kode itu? Apakah soal ada seseorang yang bisa disalahkan? Saya belum tahu apakah itu cukup untuk membenarkan rasa moral yang kuat yang saya rasakan
    Saya khawatir emosi kuat ini bukan syarat penting bagi engineering yang baik, melainkan lebih dekat ke selera pribadi. Orang tentu boleh punya preferensi, tetapi kalau memang hanya itu, maka tampaknya saya harus memperkirakan sisi pekerjaan ini akan jadi kurang menyenangkan ke depannya. Pada akhirnya saya seperti terdorong ke posisi manajer, hanya saja bawahan saya adalah bot

  • Dikatakan bahwa “Zig memungkinkan tim kecil memprototaip runtime JS berperforma tinggi dengan cepat tanpa garbage collector dan runtime yang berat”, tetapi runtime besar lain yaitu Node dan Deno juga melakukan hal yang sama
    Keduanya membungkus engine JS dengan bahasa tanpa garbage collector, yaitu C++ dan Rust. Saya tidak terlalu tahu apakah V8 atau JSC sendiri pada praktiknya mendistribusikan garbage collector juga, tetapi itu bukan inti persoalannya

  • Seluruh repositori Bun terasa seperti distopia. Bot-bot saling bercakap-cakap sambil membuat PR yang tidak masuk akal
    Contoh: https://github.com/oven-sh/bun/issues/30766

  • Kecepatan ini dianggap “selesai” memang cukup mengejutkan, tetapi saya tidak melihatnya sebagai kecelakaan kereta yang sedang berlangsung seperti yang digambarkan tulisan itu tanpa bukti kuat
    Pernyataan bahwa “enam bulan lagi muncul bug konkurensi aneh, lalu suatu edge case di bawah beban tertentu memicu perilaku tak normal, dan engineer yang men-debug akan berhadapan dengan sistem yang tak pernah benar-benar dipahami siapa pun” murni spekulasi dan tidak disertai fakta
    Port bahasa adalah area yang cocok untuk LLM, dan kode dasarnya juga sudah dipahami banyak manusia. Saya tidak mengerti kenapa port bahasa yang sederhana tiba-tiba dianggap akan merusak kemudahan diagnosis secara permanen