Bagaimana perkembangan penulisan ulang Bun ke Rust?

• Meski dikenal sebagai pekerjaan yang selesai dalam 11 hari, hingga 27 Juli 2026, 6 minggu setelah digabung ke main, masih belum ada tag rilis dan pekerjaan terkait terus berlanjut
• Penulisan ulang awal menghabiskan biaya API Anthropic sebesar 165 ribu dolar pada 3–14 Mei 2026, tetapi tampaknya tidak termasuk biaya Buildkite CI/CD dan pekerjaan lanjutan
• PR terbuka milik robobun meningkat dari 1.277 pada 9 Juli menjadi 2.475 pada 27 Juli; jika pipeline memakan waktu sekitar 40 menit per PR, diperlukan eksekusi terus-menerus selama 86 hari untuk memproses semuanya
• Penggunaan Claude melonjak bersamaan dengan dimulainya penulisan ulang, dan partisipasi robobun serta karyawan Anthropic dalam pekerjaan Rust juga meningkat, sehingga waktu selesai dan total biaya sebenarnya sulit dipastikan hanya 165 ribu dolar
• Karena tim Bun tidak secara langsung menyatakan penulisan ulang telah selesai maupun total biayanya, jika ingin menjadikan capaian coding AI sebagai dasar penilaian valuasi perusahaan, perlu melihat nilai dibanding biaya dan intervensi manusia yang berkelanjutan

---

Penulisan ulang yang terus berlanjut setelah penggabungan

• Jarred Sumner mengungkapkan dalam Rewriting Bun in Rust bahwa ia menghabiskan 165 ribu dolar untuk panggilan API Anthropic selama 11 hari pada 3–14 Mei 2026 dan menggabungkan hasil penulisan ulang ke main
  • Sekitar 15 ribu dolar per hari, skala yang sulit ditanggung banyak pemelihara open source
  • Biaya CI/CD yang tampaknya terus berjalan di klaster Buildkite milik organisasi kemungkinan tidak termasuk dalam angka ini
• Per 27 Juli 2026, sudah 6 minggu sejak penggabungan tetapi belum ada tag rilis baru, dan sudah 11 minggu sejak tag terakhir bun-v1.3.14
  • Sebelumnya, jeda rilis lebih dari sebulan hanya pernah terjadi selama 6 minggu, dari v0.2.2 pada 26 Oktober 2022 hingga v0.3.0 pada 7 Desember
• PR terbuka robobun``, metrik proksi untuk PR yang dibuat Claude Code, bertambah dari 1.277 pada 9 Juli menjadi 2.475 pada 27 Juli
  • Teramati bahwa pemeriksaan Buildkite dan penggabungan ke main umumnya memakan waktu sekitar 40 menit, kadang sampai 1 jam 30 menit
  • Jika menerapkan 40 menit per PR, untuk menggabungkan seluruh 2.475 PR diperlukan pipeline yang berjalan terus selama 86 hari
  • Sebagian PR tidak terkait dengan kode Rust, dan ada juga PR individu yang melalui peninjauan sangat banyak

Perbedaan antara biaya yang dipublikasikan dan sumber daya yang benar-benar dikeluarkan

• Pada saat penulisan ulang dimulai, penggunaan Claude meningkat tajam, dan setelah itu terlihat tren naik dalam partisipasi karyawan Anthropic dan robobun pada pekerjaan Rust
  • Analisis ini mencakup asumsi bahwa commit Jarred Sumner selama periode penulisan ulang menggunakan Claude
  • Karena sebagian PR ditulis oleh karyawan Anthropic, yang perlu dipertimbangkan bukan hanya biaya token tetapi juga keterlibatan langsung karyawan
• Jika diasumsikan penulisan ulang terus menelan biaya 10 ribu dolar per hari, biaya kumulatifnya mendekati 800 ribu dolar, tetapi ini adalah estimasi berdasarkan asumsi, bukan biaya nyata yang dipublikasikan
• Tim Bun tidak pernah menyatakan bahwa penulisan ulang sudah sepenuhnya selesai atau bahwa total biayanya hanya 165 ribu dolar
  • Sulit menerima dari kasus ini saja bahwa AI sudah menggantikan pekerjaan pemelihara open source dengan lebih cepat
  • Anthropic sedang menerapkan alatnya secara internal, dan pekerjaan otomatisasi serta partisipasi karyawan juga terus berlangsung
• Alih-alih menolak AI itu sendiri, yang perlu diwaspadai adalah ekspektasi berlebihan dan penilaian valuasi perusahaan saat ini; perlu ditelaah apakah nilainya sepadan dengan biaya yang dikeluarkan dan apakah valuasi perusahaan tersebut memang layak
• C compiler milik Anthropic dan browser web FastRender milik Cursor tidak memiliki commit selama beberapa bulan

[GN⁺]

Komentar Hacker News

• Versi tulis ulang Rust dari Bun sudah berjalan di Claude Code selama lebih dari sebulan, tetapi hampir tak ada yang menyadarinya, dan secara umum berjalan dengan baik
  Mereka tidak akan merilisnya sebelum lolos uji kompatibilitas Node.js seperti yang dijanjikan di video Bun v1.4, dan jika PR terkait digabungkan, kemungkinan besar v1.4 akan dirilis sekitar Selasa minggu depan

  • Tidak masalah memakai waktu sebanyak yang diperlukan demi kualitas perangkat lunak. Tidak ada rilis selama sebulan bukan masalah besar, dan jika ada fitur tertentu yang mendesak, orang bisa berkontribusi atau membangunnya sendiri
    Bahkan Node.js, selain perbaikan keamanan, juga sering tidak memiliki rilis yang berarti selama 4~6 minggu tiap Desember, jadi kritik kali ini yang langsung menulis dengan marah tanpa bertanya dulu kepada pihak terkait terasa kurang berdasar. Ini dikatakan sebagai maintainer Node.js
  • Claude Code sendiri sering memiliki bug dan gangguan setelah rilis, jadi tidak mengherankan jika pengguna tidak bisa membedakan bug yang muncul karena peralihan Bun berbasis Rust dari bug yang biasa ada
  • Ingin tahu apakah ada yang bisa menjawab estimasi biaya dalam tulisan itu, khususnya biaya Buildkite
  • Bisa dipahami mengapa ada yang khawatir tentang masa depan Bun, karena banyak proyek vibe coding yang mulai sangat kuat lalu berakhir terbengkalai seperti Anthropic C. Bun cepat dan enak dipakai, jadi semoga bisa bertahan lama seperti GCC

• Setelah refactor besar atau penulisan ulang skala besar, biasanya butuh waktu untuk kembali ke kecepatan pengembangan normal, jadi sulit menilai banyak hal hanya dari jumlah commit dan ritme rilis
  Walaupun para pengembang sudah akrab dengan strukturnya, mereka tetap harus beradaptasi ulang dengan codebase Rust, dan mungkin sedang fokus pada hal seperti melacak penggunaan unsafe ketimbang fitur untuk pengguna. Di kanal canary juga hampir tidak terdeteksi masalah besar atau perubahan besar, jadi ada alasan kuat untuk membereskan pekerjaan yang tertunda alih-alih buru-buru merilis
  Compiler C milik Anthropic dan browser FastRender milik Cursor dipandang bukan sebagai proyek jangka panjang, melainkan eksperimen kapabilitas, dan semoga sekarang tidak ada orang yang benar-benar memakainya

  • Semua pengguna Claude Code sudah dipindahkan ke versi baru sebulan lalu, jadi dalam arti tertentu ini sebenarnya sudah rilis layanan produksi. Karena sorotannya besar dan tidak ada kebutuhan untuk terburu-buru merilis resmi, tampaknya mereka melakukannya secara bertahap
  • Sudut pandang biaya CI/CD menarik. Biasanya saat membantah ROI AI orang bilang banyaknya kode tidak otomatis menambah nilai, tetapi jika setiap eksekusi CI dikenai biaya, pendapatan nyata memang bertambah
    Ini juga terkait dengan fakta bahwa CI dan pengujian tambahan menjadi kunci untuk mencegah pekerjaan berulang buatan AI lepas kendali
  • Dari sudut pandang penulis artikel itu sendiri, ia juga tidak yakin seberapa jauh angka-angka ini bisa dipakai untuk menilai. Ia berharap setelah rilis berikutnya Anthropic atau Bun menerbitkan retrospektif yang mengungkap biaya keseluruhan

• Menerjemahkan proyek dalam waktu singkat dengan LLM atau membuat tiruan produk office sekaligus memang mengesankan, tetapi hakikat perangkat lunak bukanlah pembuatan awal yang cepat, melainkan pengembangan fitur dan pemeliharaan jangka panjang
  Tiruan Word pun bisa cepat membuat fungsi dasar, tetapi pada detail seperti struktur halaman, tabel, gambar, dan rotasi, LLM mulai runtuh. Bahkan jika SQLite dipindahkan dari C ke Rust dan lolos semua pengujian, besar kemungkinan tetap lebih lambat karena tidak membawa optimisasi bertahun-tahun dari implementasi lama, dan juga harus menanggung bug baru akibat perpindahan bahasa serta dukungan ke depan
  Di Reddit terus muncul proyek yang mengklaim sudah mengimplementasikan X, Y, Z, tetapi perbaikan bug, respons pengguna, keamanan, struktur data yang berubah, dan pekerjaan basis data tidak menarik, sehingga sering ditinggalkan secepat vibe coding itu sendiri
  Jika tidak benar-benar memahami perangkat lunak yang dibuat sendiri, pada akhirnya semuanya akan meledak, dan frasa menulis ulang X menjadi Z dalam Y hari sendiri tidak berarti apa-apa. Mempercepat permulaan dan memahami, mengembangkan, serta memelihara kode hasil porting adalah dua hal yang sama sekali berbeda, dan alih-alih versi Zig yang dirawat, hasil pencarian bisa tercemari oleh versi Rust yang ditinggalkan dan tulisan promosi

  • Semoga lebih banyak orang mendokumentasikan proses ini. Secara pribadi sedang belajar sambil membuat proyek yang sangat bergantung pada LLM, dan saat fitur kompleks cepat berjalan, rasanya sangat memuaskan, tetapi integrasi, perapian, dan pemolesan UI justru terasa lebih menyakitkan setelah pernah merasakan kecepatan awal itu
    Jika kode terlalu kusut oleh solusi sementara, akan sampai pada titik inersia di mana LLM tidak bisa melangkah maju tanpa menciptakan kekacauan yang lebih besar, dan akhirnya harus memperbaiki arsitektur, membuang semuanya lalu mulai lagi, atau mundur ke titik terakhir saat semuanya masih normal. Rasanya seperti mengembangkan dengan jetpack: lebih cepat mencapai tujuan, tetapi juga menabrak tembok lebih cepat dan lebih sakit
    Perdebatan apakah AI itu terbaik atau terburuk, serta persaingan soal cara memakai alat, menutupi kurangnya informasi tentang apa yang berhasil dan gagal, serta bagaimana perilaku perlu diubah saat menggunakannya. Ia juga ingin menulis pengalaman langsung, tetapi terus menundanya karena lebih menyenangkan membuat fitur baru atau memperbaiki cacat UI
  • Di GitHub, bahkan sebelum era LLM, sudah ada ribuan game engine dan compiler untuk bahasa virtual yang terbengkalai. Di forum OS pada awal 2000-an pun hampir semua orang membuat OS mereka sendiri, dan beberapa bahkan bisa menjalankan Firefox
    Tidak semua perangkat lunak harus komersial atau sangat matang agar berguna; eksperimen untuk belajar saja pun sudah bisa memberi banyak pelajaran
  • Semakin dalam secara teknis, semakin mudah dianggap bisa digantikan. Ini karena orang menerima asumsi bahwa di dalam organisasi, nilai diciptakan oleh kemampuan teknis murni, bukan oleh diri seseorang atau relasinya
    Namun tampaknya orang mulai menerima kenyataan bahwa faktor kebetulan seperti efek jaringan, kepemilikan, dan akuntabilitas juga penting. Hanya saja ada paradoks bahwa banyak teknolog masuk ke ranah teknis justru untuk menghindari nepotisme, penilaian sewenang-wenang, dan lingkungan yang lebih mementingkan omong besar daripada teknologi yang terkait dengan faktor-faktor itu
  • Ada yang pernah bekerja di startup yang benar-benar menulis ulang codebase besar sambil menghentikan pengembangan fitur, tetapi ketika kembali setelah melewatkan seluruh proses karena menangani proyek lain, kurva belajarnya hampir tidak ada. Itu karena arsitektur inti, struktur data, dan konsep-nya tetap sama meski bahasanya berbeda
    Bun juga bukan didesain ulang dari nol, melainkan pertama-tama dipindahkan apa adanya ke bahasa baru. Bahkan dilihat dari pengalaman sebelum era LLM, jika ingin tim cepat beralih, pendekatan yang benar adalah memindahkan ke bahasa lain sesederhana dan secepat mungkin, dan meminimalkan masa penulisan ulang selama X hari adalah tujuan yang baik
  • Sikap tidak memahami secara mendalam kode yang ditulis sendiri adalah bentuk jangka pendekisme ekstrem. Para maintainer akan belajar dengan susah payah di mana batas antara kode hasil AI dan kode yang masih bisa dipelihara manusia

• Seseorang disebut berhasil memodernisasi implementasi Zig asli, menerapkan praktik terbaik, dan memperbaiki bug hingga mencapai incremental build di bawah 1 detik. Ini mengisyaratkan bahwa masalah yang dipakai untuk membenarkan penulisan ulang sebenarnya dibuat sendiri dan bisa diselesaikan
  https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
  Versi Zig juga memakai LLM, jadi ini tidak ada hubungannya dengan perang budaya. Orang yang benar-benar memahami domain masalah selalu bisa menghasilkan hasil yang lebih baik daripada orang yang hanya menghamburkan sumber daya seperti token senilai ratusan ribu dolar

  • Inti pembenaran penulisan ulang itu bukan kecepatan build, melainkan bug memori yang muncul khususnya saat berinteraksi dengan objek JavaScript yang dikelola garbage collector. Zig tidak punya cara umum untuk mencegah hal ini, dan juga tidak tampak ada klaim bahwa Buz telah menyelesaikannya
  • Proyek ini terlihat lebih seperti meme atau lelucon daripada upaya serius. Basis kode lama sepanjang 600 ribu baris disebut sebagai kode berantakan buatan AI, dan mereka menyatakan akan menolak kontribusi yang ditulis manusia sampai sebagian besar subsistem selesai ditulis ulang
    Sulit menganggap serius proyek yang merapikan kode berantakan dengan LLM sambil melarang kontribusi manusia

• Berkat penulisan ulang Bun, mereka jadi jauh lebih berani mencoba porting dan penulisan ulang kode, serta mem-vendor dependensi eksternal, sehingga bisa lebih disesuaikan untuk kebutuhan internal meski mungkin tidak cocok untuk proyek hulu
  Mereka juga jadi memberi model coding pekerjaan yang lebih ambisius, sambil jauh lebih fokus pada perangkat pengujian dan verifikasi di luar batas bahasa. Meski pernah ikut penulisan ulang besar selama bertahun-tahun, Bun yang menjaga pengujian dan kesetaraan fungsional sambil tetap menambahkan perbaikan dinilai sebagai keberhasilan rekayasa yang luar biasa

• Banyak kecaman dramatis dan serangan pribadi dalam diskusi seputar penulisan ulang Bun, seolah masing-masing memproyeksikan kepentingan ideologis yang lebih dalam. Tulisan ini skeptis terhadap seberapa sukses AI dapat menggantikan programmer, dan poin dari maintainer Zig lebih dekat ke etika open source dan masa depan di era LLM
  Dari sudut pandang yang optimistis terhadap kemampuan AI, tidak banyak alasan untuk meragukan bahwa pengembang terampil bisa mengarahkan LLM mutakhir untuk menerjemahkan seluruh library. Pertanyaan lanjutan yang lebih penting adalah biaya saat ini dan apakah ke depan akan terjadi pemisahan antara kubu yang sepenuhnya mengadopsi AI dan kubu yang tidak

  • Tidak ada seorang pun di tim yang punya pengalaman Rust
  • Porting Bun dari Zig ke Rust hampir tidak memberi pelajaran yang bisa digeneralisasi tentang Zig, Rust, porting bahasa, atau cara memakai LLM. Ada terlalu banyak karakteristik pada basis kode sebelum dan sesudah yang sulit dikuantifikasi, dan preferensi terhadap bahasa, cara porting, serta coding dengan LLM juga ikut campur
    Jika hasilnya tidak sama atau biaya token lebih mahal, orang bisa bilang alatnya dipakai dengan salah; jika hasilnya mengecewakan, bisa lolos dengan alasan itu hanya pembuktian konsep dan model dalam 6 bulan terakhir sudah membaik sehingga tak bisa dibandingkan, jadi sulit memperoleh kesimpulan yang bisa diverifikasi
  • LLM sangat mahir menghasilkan keluaran yang tampak meyakinkan tetapi salah, jadi ada banyak alasan untuk bersikap skeptis. Terlepas dari benar atau tidaknya hasil kerja ini, jelas ini adalah acara pemasaran, dan Anthropic punya riwayat membuat pengumuman yang berlebihan atau tidak akurat sehingga perlu verifikasi yang lebih ketat

• Saya curiga bahkan pengumuman yang menyatakan kemenangan dan analisis mendalam yang tampak jujur pun agak terburu-buru
  Risiko utama demam LLM adalah ia memberi hasil instan kepada pengembang berpengalaman yang lelah mengetik dan berpikir manual, sambil mempertaruhkan pengalaman perangkat lunak yang terakumulasi selama puluhan tahun. Tagihan biaya yang sebenarnya datang jauh belakangan

  • Mengetik memang hal sekunder dalam rekayasa perangkat lunak, tetapi bila bottleneck-nya benar-benar ada di pengetikan, LLM bisa bernilai. Hanya saja situasi seperti itu jarang

• Akan meningkatkan kredibilitas jika tulisan itu mencerminkan fakta bahwa Bun berbasis Rust sudah berjalan di Claude Code sejak 17 Juni dan juga tersedia sebagai versi canary setelah masuk ke main. Untuk penulisan ulang sebesar ini, periode canary yang panjang sangat masuk akal

  • Tulisan itu sudah membahas pemakaian internal di Anthropic

• Mungkin Anthropic memang tidak terlalu tertarik merilis versi berikutnya secara publik. Versi Rust sudah berjalan lebih dari sebulan di Claude Code yang dipakai jutaan orang, dan mungkin tujuan mereka mengakuisisi Bun memang untuk Claude Code
  Proyek open source itu sendiri mungkin tidak terlalu penting bagi mereka

  • Jika yang benar-benar penting hanya Claude Code, akan jauh lebih efisien untuk menulis ulang Claude Code itu sendiri dalam Rust daripada mengganti bahasa runtime TypeScript. Biaya sekitar 800 ribu dolar kemungkinan berasal dari anggaran pemasaran Anthropic yang mengincar dampak promosi besar
  • Kecil kemungkinan mereka akan meninggalkan komunitas yang lebih luas, dan makin banyak pengguna lain juga menguntungkan Anthropic. Jika ada masalah pada rilis ini, mereka bisa menerima kritik keras dan kepercayaan komunitas bisa rusak, jadi tampaknya mereka lebih berhati-hati dari biasanya
  • Bun adalah komponen utama dalam ekosistem web, jadi fakta bahwa Anthropic mengembangkannya dengan AI sendiri memberi efek promosi yang sangat besar
  • Claude Code tampaknya bisa berjalan di runtime JavaScript mana pun, jadi jadi penasaran mengapa Bun diperlukan
  • Pada akhirnya ini tampak seperti acara pemasaran untuk mengiklankan penulisan ulang kode berbasis Claude. Pesan bahwa untuk menyingkirkan basis kode yang tidak nyaman, Anda cukup menghabiskan banyak uang ke Anthropic, berhasil tersampaikan
    Jika tujuannya Claude Code, mereka bisa mulai dengan menulis ulang itu terlebih dahulu, dan jika selama ini ditekankan bahwa mereka tak lagi menulis kode secara langsung, maka bahasa implementasi seharusnya juga tidak penting

• Siapa pun yang pernah menulis ulang perangkat lunak bisa memahami tahap saat ini. Sebagian besar sudah berfungsi, tetapi tetap harus terus diperbaiki agar tidak ada regresi, dan tekanan yang menyertai rilis juga sangat besar
  Saya rasa keputusan untuk menulis ulang itu benar, tetapi saya tidak ingin langsung menerapkannya ke lingkungan produksi sejak awal. Akan mengurangi beban jika Jarred menyediakan release candidate terlebih dahulu alih-alih langsung merilis versi stabil