Claude Code menggunakan Bun yang ditulis ulang dengan Rust

• Mulai v2.1.181, Claude Code menyertakan Bun yang di-porting ke Rust, sehingga kecepatan startup di Linux menjadi 10% lebih cepat, tetapi sebagian besar pengguna hampir tidak menyadari perubahannya
• Dengan memeriksa string di file eksekusi, dapat ditemukan Bun v1.4.0 yang belum memiliki tag resmi, beserta path file sumber Rust
• Di ~/.local/bin/claude, ditemukan 563 nama file .rs termasuk src/runtime/bake/dev_server/mod.rs
• Versi tertanam 1.4.0 juga dapat diverifikasi dengan memuat lebih dulu file TypeScript melalui BUN_OPTIONS lalu menampilkan Bun.version
• Versi Rust telah didistribusikan sebagai Bun canary, dan melalui Claude Code sudah berjalan di produksi pada jutaan perangkat

---

Bun berbasis Rust yang tertanam di Claude Code

• Menurut Rewriting Bun in Rust, mulai Claude Code v2.1.181 yang dirilis pada 17 Juni, digunakan port Rust
  • Kecepatan startup di Linux meningkat 10%
  • Selain itu, perbedaan lain hampir tidak disadari pengguna, dan Jarred Sumner menilai ini sebagai “Boring is good”
  • Melalui Claude Code, ini sudah berjalan di produksi pada jutaan perangkat
• Versi Bun tertanam dapat ditemukan dari string di file eksekusi Claude

strings ~/.local/bin/claude | grep -m1 'Bun v1'

• Di lingkungan macOS arm64, output yang muncul adalah Bun v1.4.0 (macOS arm64)
• Karena rilis stabil terbaru di GitHub saat itu adalah Bun v1.3.14 pada 12 Mei, berarti Claude Code menyertakan pratinjau v1.4.0 yang belum dirilis resmi
• Versi Rust telah dipublikasikan sebagai Bun canary, dan dapat diinstal dengan bun upgrade --canary

Verifikasi sumber Rust dan versinya

• Jika path sumber Rust diekstrak dari file eksekusi, dapat dilihat 563 nama file

strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'

• Daftarnya mencakup path berikut

src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs

• Metode yang dibagikan Ajan Raj memuat lebih dulu file TypeScript dengan BUN_OPTIONS, lalu langsung menampilkan Bun.version yang tertanam di Claude Code

cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version

• Perintah ini juga menampilkan 1.4.0
• Pada commit 17 Mei, versi package.json diubah menjadi 1.4.0 dan tetap seperti itu, tetapi hingga kini masih belum dimasukkan ke rilis bertag selain canary

[GN⁺]

Pendapat di Hacker News

• Sulit memahami mengapa TUI harus lewat JavaScript dan dijalankan di React untuk terminal. Fakta bahwa Anthropic sampai mengakuisisi runtime demi meningkatkan TUI justru makin membuat kualitas engineering-nya diragukan. Jika penulisan ulang semudah itu, memindahkan Claude Code ke bahasa native pasti jauh lebih murah

  • Karena ini bisnis yang sudah berjalan baik dan menghasilkan pendapatan besar, pertanyaan “mengapa teknologi ini?” lebih dekat ke pilihan bisnis daripada teknis. Teknologi yang dipilih di awal menjalankan fungsinya, jadi meski arsitekturnya tidak sempurna, alasan untuk menggantinya kecil
    Penulisan ulang bahkan untuk Bun pun tidak mudah, dan tool pengembangan non-UI dengan kontrak API serta pengujian yang jelas lebih mudah dipercaya setelah ditulis ulang dibanding tool UI yang fiturnya samar dan pengujiannya kurang
  • Saat memakai Claude, OpenCode, dan Ghostty bersama-sama, program terminal interaktif sangat menguras CPU dan baterai, bahkan laptop yang semalaman dalam mode sleep pun menjadi panas. Padahal ada preseden lebih dari 40 tahun seperti curses/ncurses, Emacs, Vim, sampai MS-DOS, jadi penasaran mengapa teknologi web dipaksakan masuk
  • Saya membaca tulisan bahwa perusahaan Haskell terkenal beralih ke Python karena kecepatan iterasi pengembangan dengan memanfaatkan LLM. Data pelatihan React sangat banyak dan waktu kompilasi TypeScript juga lebih singkat dibanding Rust dan lainnya
    Kode yang berhadapan dengan pengguna dan lapisan UX yang cepat berubah kemungkinan besar akan memakai sistem dinamis yang memungkinkan iterasi pengembangan cepat, sementara lapisan infrastruktur akan pindah ke lingkungan sistem yang aman seperti Rust. Java/C# berada di tengah, tetapi ke depan untuk UX TypeScript/Python sudah cukup, sedangkan untuk pekerjaan sistem Rust lebih cocok, sehingga posisinya tampaknya akan menyusut
    https://avi.press/posts/2026-07-10-after-7-years-in-producti...
  • Jika diasumsikan Anthropic menulis Claude Code dengan AI, JavaScript juga bukan pilihan buruk. Data pelatihannya melimpah, dan bisa menghindari masalah multithreading dan manajemen memori yang dapat membingungkan AI di bahasa berkinerja tinggi lain, sehingga cocok untuk membuat software dengan cepat menggunakan AI
  • OpenAI memutuskan sekitar setahun lalu untuk menulis ulang Codex dengan Rust. Jika penulisan ulang benar-benar mudah, perlu juga ditanyakan mengapa Bun dibutuhkan dan mengapa tidak memindahkan semua kode JavaScript ke Rust
    https://github.com/openai/codex/discussions/1174

• Dari tulisan asli Jarred, terlihat jelas bahwa alasan perpindahannya adalah bagian yang di Zig harus dikerjakan manual menjadi otomatis di Rust. Baik manusia maupun agen bersifat nondeterministik, jadi jika masa hidup memori dan pembebasan eksplisit di Zig harus dilacak secara manual, bug yang terlewat akan menumpuk panjang; Rust menghilangkan kelas error ini dan menjadi kompromi yang baik dari sisi manajemen engineering
  Khususnya, error compiler adalah pagar pengaman deterministik yang dibutuhkan agen coding, dan jika Claude diberi cara untuk menguji ketepatan serta target “buat agar bisa dikompilasi”, hasilnya berjalan baik. Pendekatan umum yang mengubah keluaran probabilistik menjadi jaminan pasti melalui pengujian deterministik saya rangkum di https://michael.roth.rocks/blog/verification-surface/

  • Zig dan C tidak cocok ketika membuat banyak alokasi kecil yang masa hidupnya saling tidak terkait. Agar kokoh, Anda harus mengelola masa hidup sendiri, misalnya mengikat alokasi ke arena atau memakai buffer tetap
    Dengan begitu Zig juga bisa sekokoh Rust, tetapi jika menginginkan pola alokasi ala bahasa managed yang disukai LLM, Zig bukan pilihan yang tepat
  • Yang menangani otomatis adalah bahasa dengan garbage collection. Di Rust pun masa hidup memori tetap harus dipikirkan dan dilacak, tetapi borrow checker mencegah penanganan yang salah dan memberi umpan balik perbaikan segera, sehingga cocok dipakai LLM. Parameter referensi immutable secara default juga membantu mencegah masalah performa besar
  • Saya ragu apakah bisa dikatakan kelas error otomatis dihilangkan, padahal saat ini Bun berisi sangat banyak Rust unsafe: https://news.ycombinator.com/item?id=48967630
  • Menurut pengalaman saya, LLM cukup mudah menemukan bug memori. Peristiwa ini tampak tidak lebih dari aksi pemasaran Anthropic yang sukses
  • Sepingat saya, penulisan ulang Rust kali ini seluruhnya unsafe, jadi kemungkinan besar masalah tersebut tidak otomatis dihilangkan

• Terlepas dari penilaian Jarred atau Simon Willison, saya memandang hal ini cukup negatif. Masalah yang lebih besar daripada akuisisi Bun oleh Anthropic atau penulisan ulang dengan AI adalah cara pelaksanaannya yang tidak matang: bermula dari sikap “ini hanya branch saya dan orang-orang bereaksi berlebihan”, lalu menggabungkan PR lebih dari 1 juta baris dalam waktu kurang dari sebulan
  Komunikasinya sangat keliru sehingga merusak kepercayaan dan memperbesar perpecahan, dan saya bertanya-tanya apakah memang sesulit itu mengikuti pendekatan yang diambil tim TypeScript pada 7.0

  • Pada akhirnya sebagian besar pengguna Claude Code mungkin tidak menyadari atau tidak peduli, dan pihak yang mempermasalahkannya sangat sedikit, jadi secara praktis mungkin tidak penting
  • TS7 juga merupakan contoh representatif dari porting baris demi baris ke bahasa lain, alih-alih meninjau arsitektur secara serius

• Bun v1.4.0 yang disertakan di Claude tampaknya adalah versi pratinjau yang belum dirilis. Jika begitu, tampaknya proyek FOSS Bun diam-diam berubah menjadi sesuatu yang lain, jadi untung saya hanya menyisakan investigasi sebagai TODO dan tidak mengadopsinya
  Saya tidak bisa menemukan dokumen tata kelola Bun, dan penasaran apakah sekarang strukturnya pada dasarnya Anthropic yang menentukan semua pekerjaan dan apakah akan digabungkan

  • Sulit memahami kesimpulan bahwa proyek akan mati karena beralih ke Rust
  • PR-nya publik, siapa pun bisa membangun dan memakainya; hanya saja tim Anthropic memutuskan untuk memakainya lebih dulu
  • Setahu saya, strukturnya pada dasarnya bergantung pada apakah Jarred bersedia menerimanya minggu itu. Catatan perubahan Claude Code sudah mencantumkan perubahan versi Bun 1.4.0 sejak hampir sebulan lalu, tetapi karena catatan itu ditulis AI, tidak aneh jika kebanyakan orang tidak membacanya
  • Saya juga pernah meneliti adopsi Bun lalu memutuskan tidak memakainya karena ketidakstabilan, dan melihat kejadian ini rasanya keputusan itu tepat

• Saya tidak mengerti mengapa mereka memprosesnya dengan cara serumit ini di sekitar Bun. Jika agen bisa memindahkan Zig ke Rust, Claude Code juga seharusnya bisa ditulis ulang langsung ke Rust dari JavaScript untuk menghilangkan dependensi runtime dan meningkatkan performa

  • Jika melihat penulisan ulang Bun ke Rust sebagai sesuatu yang pada dasarnya tidak ada hubungannya dengan strategi produk Anthropic, tidak ada alasan untuk bingung
  • Kalau hanya melihat Claude Code, penulisan ulang langsung ke Rust mungkin lebih baik, tetapi dengan begitu nilai akuisisi Bun/oven.sh akan jauh berkurang
    Selain Claude Code, Bun kemungkinan juga punya pengguna eksternal dan pengguna internal Anthropic, serta memberi mereka runtime JavaScript dan ekosistem alat yang mungkin disukai model coding. Ke depannya Anthropic bahkan bisa menyediakan cloud yang dikhususkan untuk menjalankan dan mengelola aplikasi semacam ini, dan sekadar memperoleh komunitas developer saja akan memberi pengaruh yang jauh lebih besar daripada memindahkan satu Claude Code ke Rust
  • Saya juga ragu apakah Claude Code benar-benar mengalami bottleneck performa. Runtime JavaScript punya ekosistem alat yang besar dan memudahkan pengembangan plugin, jadi sudah cukup layak

• Jika mengesampingkan spekulasi dan emosi, yang sebenarnya saya penasaran adalah kualitas eksekusinya. Bukan hanya kecepatan startup, tetapi juga penggunaan RAM dan CPU, serta apakah ada loop tak berujung atau deadlock; jika sama seperti sebelumnya atau lebih baik, itu cukup mengesankan
  Sebagai developer, saya tidak suka kemungkinan AI mengambil pekerjaan, tetapi jika siapa pun bisa membuat software yang diinginkan hanya dengan permintaan sederhana, itu bisa memperbaiki dunia. Jika tidak suka pengumpulan data Microsoft, kita bisa meminta AI membuat sistem operasi; jika tidak suka penyadapan Google, kita bisa meminta AI membuat ponsel. Kemandirian teknis seperti itu bisa menjadi mungkin, dan di hadapannya stabilitas kerja pribadi menjadi hal kecil
  Karena itu, semakin penting untuk menjaga teknologi tetap open source; jika tidak, kita hanya akan mengulang struktur monopoli lama sekaligus kehilangan pekerjaan

  • Bagian tersulit dalam pengembangan software adalah mendapatkan requirement yang jelas. Bahkan dengan AGI sempurna, orang tidak bisa mengungkapkan dengan jelas apa yang mereka inginkan, jadi dunia tempat semua orang membuat software yang persis mereka inginkan tidak akan terjadi
  • Alat yang bagus pun baru menghasilkan hasil luar biasa jika digunakan oleh perajin yang terampil. Developer yang baik mengajukan pertanyaan yang tepat, membangun safeguard, dan bisa menyesuaikan hasil secara langsung di tempat yang diperlukan
  • Menyebut model tertutup di balik paywall berbayar yang saat ini disubsidi sebagai demokratisasi teknologi itu terlalu naif. Strategi memanfaatkan porting Bun ke Rust terutama untuk tujuan marketing tampaknya berhasil dengan baik

• Baru-baru ini saat memakai Claude Code di dalam tab Kitty, saya mengalami segmentation fault, lalu seluruh tab tidak lagi merespons input. Link pelaporan muncul, tetapi tidak bisa diklik dan sudah dienkode sehingga saya juga tidak bisa memastikan informasi apa yang dikirim

  • Dari sisi ide dan fitur, Bun jauh lebih unggul daripada runtime JavaScript lain, tetapi stabilitasnya buruk sekali, dan jumlah segmentation fault sekitar 20 kali lebih banyak daripada Node. Angka ini berdasarkan data telemetri New Relic
  • Jika shell tidak menampilkan Segmentation fault, kemungkinan besar itu bukan segmentation fault melainkan hang. Jika benar-benar error, setelah kembali ke shell Anda bisa mengetik reset untuk memulihkan tab meskipun tidak terlihat di layar
  • Saya memakai Ghostty dan Claude Code di MacBook kerja, tetapi belum pernah mengalami masalah ini. Dulu ada memory leak yang tak terkendali hingga sistem hang dan harus reboot, tetapi dalam beberapa minggu terakhir sudah hilang; masih terlalu dini untuk menyimpulkan, tetapi ada kemungkinan porting ke Rust mengurangi memory leak
  • Saat memakai antarmuka pertanyaan interaktif Claude di Ghostty, terjadi hang yang mirip; selain scroll, tidak ada input apa pun yang diterima, termasuk memilih atau membatalkan. Namun saya tidak menganggap ini terkait dengan Bun
  • Versi Zig juga punya segmentation fault, dan jika dipindahkan baris demi baris ke unsafe Rust, kode penyebabnya juga akan tetap ada. Masalah itu tidak akan terselesaikan sebelum direfaktor menjadi Rust yang idiomatis dan memory-safe

• Mereka terlihat seperti engineer yang sangat sukses tetapi buruk, yang pandai mendeskripsikan masalah dan memiliki anggaran token tak terbatas. Jika mereka menanggung sendiri biaya token, akan ada insentif finansial untuk meningkatkan efisiensi software
  Realitas tersembunyi dari data center AI adalah meskipun efisiensi klaster GPU hanya 40–60%, mereka menutupinya dengan membeli lebih banyak perangkat menggunakan dana. Alasan mereka takut pada pesaing China mungkin karena pesaing itu tidak punya kemewahan untuk membuang-buang sumber daya seperti mereka

• Pekerjaan ini adalah transpile, dan kualitasnya juga tidak bagus. Kode yang dihasilkan jauh dari Rust idiomatis, sampai bisa disebut mengerikan

  • Meski begitu, tampaknya berfungsi dengan benar. Kali ini pada dasarnya masih tahap awal yang memindahkan kode secara mekanis baris demi baris, dan tahap berikutnya direncanakan untuk merapikannya menjadi Rust idiomatis, jadi sepertinya bukan ide bagus untuk terus bertaruh melawan penulisan ulang ini
  • Jika mempertimbangkan stabilitas, efisiensi, dan biaya, akan jauh lebih masuk akal menggunakan atau menulis translator antar-sumber yang mempertahankan struktur asli semaksimal mungkin
    Biasanya dalam penulisan ulang, pelajaran dari codebase lama ikut tercermin, tetapi jika porting dilakukan per file oleh agen, manfaat itu tidak ada. Bagaimanapun hasilnya akan menjadi terjemahan yang tidak idiomatis, tetapi dengan LLM ditambahkan pula nondeterminisme dan biaya yang sangat besar
  • Perlu contoh konkret kode Rust yang disebut mengerikan itu
  • Saya penasaran mengapa mereka tidak langsung melakukan transpile ke LLVM IR saja
  • Jika proyeknya mencapai tujuan memory safety, saya ragu apakah kode yang idiomatis benar-benar penting

• Belakangan Claude Code jauh lebih tidak stabil daripada sebelumnya, dan error rendering TUI sering membuat riwayat percakapan rusak

  • Saya memakai Claude dengan enggan sejak Februari, dan sejak awal sudah ada cacat rendering, error input keyboard, dan sebagainya; itu TUI terburuk yang pernah saya gunakan. Namun dalam seminggu terakhir malah semakin buruk, sampai mulai merusak sesi terminal, misalnya sebagian karakter yang saya ketik tidak terlihat
    Jika dikirim ke background, menjalankan reset, lalu membawanya kembali ke foreground, masalahnya teratasi. Saat saya meminta Claude mendiagnosisnya, ia mengatakan tidak punya bug seperti itu dan menyalahkan program lain, padahal yang berjalan hanya tmux dan Claude. Jika versi Rust baru-baru ini diterapkan, waktunya kira-kira cocok dengan penurunan kualitas ini
  • Di Windows, setiap kali ukuran jendela diubah, output menjadi benar-benar kacau sehingga saya harus meminta ulang jawaban yang baru saja diberikan. Ini bukan masalah baru, tetapi belakangan terasa semakin parah
  • Saya tidak menentang AI itu sendiri, tetapi Anthropic sudah melangkah terlalu jauh dengan merilis kode berkualitas rendah buatan AI. Engineer sungguhan harus terus terlibat untuk mengarahkan alat, tetapi Anthropic tampaknya ingin menyerahkan 100% kode kepada AI