Buz – fork Bun yang mendukung Zig terbaru dan build inkremental di bawah 1 detik

• Buz adalah fork tahap awal yang berangkat dari commit tepat sebelum Bun ditulis ulang ke Rust, dan sedang dikembangkan dengan tujuan menjadi pengganti kompatibel berbasis Zig terbaru
• Seluruh graf build, termasuk source vendor JavaScriptCore, dipindahkan ke build.zig, dan patch kecil diterapkan ke Zig untuk mewujudkan build inkremental di bawah 1 detik
• Proyek ini mengambil test untuk fitur baru dan perbaikan bug dari Bun versi Rust, tetapi masih banyak test yang gagal, sehingga tetap perlu terus mengikuti fitur upstream dan perubahan JavaScriptCore
• Dalam proses menghapus lebih dari 11.000 baris kode yang tidak digunakan dan memodernisasi sebagian implementasi dengan berfokus pada pustaka standar Zig, sejumlah bug juga ikut diperbaiki
• Masih belum bisa dipakai di produksi, dan tujuan jangka panjangnya adalah mengurangi technical debt dengan memanfaatkan LLM bersama pengawasan manusia, lalu membangun codebase yang mudah dipelihara bahkan tanpa LLM

---

Tujuan proyek dan status pengembangan

• Buz adalah fork yang sedang dikembangkan berdasarkan commit terakhir sebelum Bun ditulis ulang ke Rust
• Fokusnya adalah menjadi pengganti yang kompatibel dengan Bun sekaligus membangun codebase yang lebih rapi dibanding sebelumnya
• Pengembangannya masih sangat awal sehingga belum siap digunakan di produksi
• Buz dipublikasikan untuk menghindari duplikasi pekerjaan pengembangan, karena proyek Bun berbasis Zig serupa sudah lebih dulu dipublikasikan di Ziggit
  • Saat dipublikasikan, proyek tersebut masih belum ditinjau

Porting ke Zig terbaru dan build inkremental

• Bun di-port ke Zig upstream saat ini, dan patch kecil diterapkan ke Zig untuk rebuild inkremental
• Seluruh graf build, termasuk source vendor JavaScriptCore, diintegrasikan ke build.zig
• Dengan konfigurasi ini, waktu build inkremental turun menjadi di bawah 1 detik, sehingga siklus iterasi pengembangan menjadi lebih cepat
• Proyek ini menyertakan submodul Zig master yang sudah diberi patch build inkremental
• Pada saat itu, build juga berjalan normal di commit Zig upstream 2b1c663

Uji kompatibilitas dan pelacakan upstream

• Test yang ditambahkan ke Bun versi Rust telah diambil, termasuk banyak test untuk memverifikasi fitur baru dan perbaikan bug
• Masih banyak test yang belum lulus, sehingga tetap perlu terus mengejar Bun upstream
• Sambil menjaga kompatibilitas fitur, penataan kode dan pengurangan technical debt juga dikerjakan secara paralel
• Perubahan JavaScriptCore juga harus terus dilacak

Penataan dan modernisasi codebase

• Menghapus lebih dari 11.000 baris kode yang sama sekali tidak digunakan di Bun
• Sebagian kode ditulis ulang dan dimodernisasi sambil memperluas penggunaan pustaka standar Zig
• Dalam proses penataan dan modernisasi, sejumlah bug juga ikut diperbaiki
• Codebase Bun saat ini berukuran sekitar 600 ribu baris, dan diperkirakan cukup banyak subsistem harus ditulis ulang untuk mencapai kondisi yang rapi

Pemanfaatan LLM dan kebijakan kontribusi

• Untuk merapikan kode lama yang kompleks, ada rencana untuk memanfaatkan LLM secara luas sambil menerapkan pengawasan manusia dan praktik pengembangan yang lebih baik
• Sampai codebase dinilai sudah cukup rapi, kontribusi yang ditulis langsung oleh manusia tidak akan diterima
• Prioritasnya adalah mengurangi technical debt dan menulis kode Zig yang idiomatis, dengan target menghasilkan codebase yang dapat dirilis dalam hitungan minggu atau bulan sebagai pengganti kompatibel untuk Rust Bun 1.4.0
• Dukungan diminta dari pengembang yang bisa menggunakan Sol atau Fable
• Dalam jangka panjang, tujuannya adalah membuat codebase yang mudah dipelihara tanpa bantuan LLM, sekaligus meningkatkan kemampuan Zig selama proses pengembangan

[GN⁺]

Pendapat Hacker News

• Fakta paling menarik dari fork ini adalah bahwa ini membuktikan Bun sebenarnya sudah lama bisa membangun dengan cepat
  Saat ini kompilasi inkremental Zig belum mendukung aarch64 dan patch biner juga hanya memungkinkan di linker Linux, tetapi dukungan untuk platform utama tampaknya tinggal menunggu waktu
  • Mengingat keributan seputar keputusan mem-fork compiler Zig demi meningkatkan kecepatan build, mengejutkan ini bukan komentar teratas
    Fakta bahwa tim 1 orang mencapai build 1 detik menunjukkan bahwa build lambat adalah hasil dari praktik pengembangan yang ceroboh, dan waktu yang dihabiskan untuk fork merupakan alokasi sumber daya yang sepenuhnya keliru
• Merapikan lagi kode yang dirusak LLM dengan LLM terasa seperti puncak teknologi di tahun 2026
  • Sampai sekarang pun manusia sudah merapikan kode yang dirusak manusia, jadi tidak ada kontradiksi logis
  • Hasil LLM akan sebaik kemampuan pengguna yang memberi instruksi
  • Saya skeptis terhadap AI tetapi bersedia memakainya; jika LLM benar-benar bisa merapikan hasilnya sendiri, itu cukup untuk mengubah keadaan
  • Saya sempat berpikir sama, tetapi tepat setelah itu dia mengatakan bahwa manusia akan tetap memegang kendali, mengurangi utang teknis, dan menulis kode Zig yang toleran sehingga dalam beberapa minggu atau bulan bisa membuat codebase yang mampu menggantikan Rust Bun 1.4.0
    Pada akhirnya ini tampak seperti soal memberi instruksi lebih banyak atau lebih baik. Struktur kode juga terasa seperti wilayah selera; kemarin saya bahkan mengalami percakapan absurd dengan seseorang yang bersikeras bahwa satu permintaan HTTP perlu empat proses backend untuk ditangani
  • Dari awal memang arahnya ke sini. Karena output LLM rusak yang tidak bisa dibaca atau dipahami manusia mulai menjadi kode, pada akhirnya semua kode mau tak mau akan dibuat agar dibaca dan ditulis mesin
    Zaman manusia ikut campur menurut saya sejak awal hanyalah tahap sementara
• Mengejutkan bahwa mereka menghapus 11.000 baris kode yang benar-benar mati di Bun, memodernkan codebase agar lebih memanfaatkan standard library, dan sekaligus memperbaiki banyak bug
  Ini hal yang umum di proyek besar, atau saya saja yang tidak tahu?
  • Totalnya 600 ribu baris, jadi kode mati itu sekitar 1,8%. Semakin besar codebase, semakin luas area yang harus ditinjau untuk menentukan apakah kode benar-benar tidak dipakai, dan seiring waktu perubahan yang berjauhan juga bisa membuat kode menjadi mati, jadi ini lebih umum
    Tidak jelas apakah ini kode yang seterang if (false) { dead_code(); }, atau kode yang secara logis tidak mungkin dipanggil meski dynamic dispatch masih memungkinkan. Jika yang pertama, 1,8% itu tinggi, tetapi jika yang kedua bisa jadi rendah; banyak proyek juga menumpuk kode di balik feature flag lama yang pada praktiknya tidak pernah lagi dijalankan
    Sedikit kode mati seperti utilitas sederhana atau generated code kadang tidak masalah dibiarkan, tetapi penghapusannya juga bisa memicu penghapusan berantai dan penyederhanaan
  • Di perusahaan sebelumnya saya menciutkan komponen 10 ribu baris menjadi 2 ribu baris sambil memperbaiki semua bug utama
    Secara ketat itu bukan kode mati, tetapi saat satu abstraksi kecil yang keliru dibersihkan, peluang perapian berikutnya terus terbuka, dan pada akhirnya yang tersisa adalah perangkat lunak yang hanya melakukan apa yang memang dimaksudkan. Codebase memang cenderung membengkak seiring waktu, jadi pada skala Bun justru lebih mengejutkan kalau mereka hanya menemukan 11.000 baris
  • Compiler Zig melakukan lazy compilation, jadi ia tidak mendeteksi fungsi mati yang tidak dipanggil dari fungsi terkompilasi mana pun
  • Mengingat cara pengembangan Bun, ini malah lebih sedikit dari perkiraan, dan kemungkinan masih ada jauh lebih banyak di codebase
  • Saya justru heran ada orang yang terkejut melihat kode mati sebanyak ini di codebase besar. Itu cuma setara sekitar 10 PR berukuran biasa
• Saya penasaran sudah berapa lama pengalaman pemrogramannya sampai menganggap 11.000 baris kode mati begitu luar biasa
  • Pengalaman saya lebih dari 10 tahun. Yang saya maksud adalah kode mati yang jelas yang tidak dipanggil dari mana pun, dan saya penasaran apakah memang banyak proyek lain dengan jumlah sebanyak ini
• Pada setiap proyek coding berpusat agen, saya melihat getaran tik-tok antara pengembangan fitur dan pengelolaan kode
  Pada fase tik, fitur ditambahkan cepat sehingga muncul versi yang benar tetapi sangat berantakan; pada fase tok, hasilnya dicerna dan dirapikan untuk meningkatkan performa, kemudahan perawatan, dan ketahanan terhadap perubahan
  Saya sering membuat aplikasi yang berjalan lewat vibe coding dalam sehari, lalu menghabiskan seminggu untuk mengubahnya menjadi proyek yang bisa terus ditambahi fitur tanpa roboh seperti rumah kartu. Sebelum AI pun mirip, tetapi pengembang profesional punya model mental sistem yang lebih kuat dan kecepatannya lebih lambat, sehingga peralihannya tidak setajam ini
  • Pada akhirnya kita tetap harus meninjau langsung kodenya dan memastikan logikanya tidak terduplikasi di mana-mana serta benar-benar bisa dirawat
    Model coding sangat cenderung mengambil jalan pintas yang merusak enkapsulasi atau menyalin kode yang seharusnya tidak diduplikasi
• Saya ingin menyebut ini pemrograman performa yang pamer. Saya suka performa dan waktu build juga seharusnya sedekat mungkin ke 0 detik, tetapi sekarang rasanya sudah masuk wilayah diminishing returns, dan bottleneck saat ini kemungkinan bukan waktu build
  • Para pengembang Bun mungkin tidak akan setuju karena mereka sendiri mengalami waktu tunggu panjang tanpa bisa memanfaatkan kompilasi inkremental: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    Pada proyek besar, tidak mungkin menunggu beberapa menit setiap kali ingin menjalankan tes atau memeriksa semantic error, jadi waktu build jelas merupakan bottleneck
  • Untuk proyek seperti ini, build cepat itu wajib, dan saya melihatnya sebagai langkah penting agar pemeliharaan lebih mudah
• Jika Bun dikelola oleh orang yang peduli pada kualitas kode, itu patut disambut, tetapi ini tugas kelas Hercules
  • Lebih mirip tugas kelas Sisifus yang berulang tanpa akhir daripada kelas Hercules
• Sebaliknya, saya juga ingin melihat fork Zig yang hanya menerima kontribusi AI
  Bukan karena sangat mendukung AI, tetapi sebagai seni konseptual atau eksperimen, akan menarik melihat bagaimana kedua proyek itu berevolusi secara berbeda
• Cruller yang sangat relevan juga memakai codebase Bun sebelum penulisan ulang, tetapi hanya berfokus pada bagian runtime untuk produksi
  Tautan: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  Diskusi HN: https://news.ycombinator.com/item?id=49017344
• Saya tidak mengerti kenapa Bun begitu ramai dibicarakan. Kenapa tidak pakai saja Node + npm + Vitest + Vite?
  • Ada proyek Nub yang mencoba menghadirkan keunggulan Bun ke Node, dan ini juga bisa menunjukkan dengan baik mengapa orang memilih Bun serta kesenjangan pada alat yang ada
    https://nubjs.com
  • Justru daftar itu sendiri yang menjelaskan kenapa ini ramai. Alih-alih merangkai banyak alat, Anda bisa memakai satu runtime yang menangani semua yang dibutuhkan
    Menggabungkan alat khusus per tujuan juga tidak masalah, tetapi sangat nyaman jika semua sudah beres dalam keadaan bawaan. Bundler Bun juga punya runtime API, jadi proses yang sama yang menyajikan aset bisa berkoordinasi dengan bundler eksternal atau melakukan bundling langsung dari memori tanpa menulis berkas statis ke disk
  • Fakta bahwa Anda harus menyebut empat alat sudah menunjukkan betapa buruknya situasi yang ada
  • Sekarang bahkan alasan untuk terus memakai npm pun sudah tidak terlalu jelas