Debat tentang Rust dalam vibe coding berpusat pada satu klaim: compiler yang ketat menangkap kesalahan hasil model bahasa sebelum kode sempat berjalan. Klaim itu punya dasar yang kuat. Analisis pada Januari 2026 mencatat 94% kegagalan kompilasi pada kode buatan LLM berupa kegagalan type check, dan tim Android Google melaporkan kerentanan keamanan memori turun dari 76% menjadi di bawah 20% setelah memakai Rust.
Yang jarang masuk perhitungan adalah biaya per putaran. Satu pemeriksaan pada proyek Rust berukuran sedang memakan 20 sampai 40 detik. Satu fitur biasanya butuh 10 sampai 15 putaran sebelum kode lolos. Hasilnya 4 sampai 10 menit menunggu untuk satu fitur, dan itu berulang sepanjang hari kerja.
Di Go, build ulang setelah satu berkas diubah sering selesai di bawah 1 detik, sehingga 15 putaran tidak terasa sebagai waktu tunggu. Perbedaan itulah yang menentukan pengalaman bekerja dengan agen, dan itu yang dihitung dalam artikel ini.
Perbandingan di sini bukan soal bahasa mana yang lebih aman, karena jawabannya sudah jelas. Yang dibandingkan adalah biaya waktu di dalam loop agen, dan bagaimana biaya itu mengubah pilihan yang masuk akal untuk tiap jenis pekerjaan.
Argumen yang benar tentang compiler
Klaim utamanya masuk akal: compiler Rust adalah pengawal yang tidak pernah lelah. Kode hasil model bahasa harus lolos type check, cek kepemilikan memori, dan cek keamanan thread sebelum bisa dijalankan. Kalau lolos, sebagian besar kelas bug tidak ada di dalamnya.
Angka yang mendukung klaim ini kuat:
| Bukti | Angka |
|---|---|
| Kesalahan kompilasi pada kode buatan LLM yang berupa kegagalan type check | 94% |
| Bug keamanan memori di Android sebelum memakai Rust | 76%, lalu turun di bawah 20% |
| Kepadatan kerentanan Rust dibanding C dan C++ di Android | sekitar 1.000 kali lebih rendah |
| CVE di Microsoft dan Chromium yang berasal dari masalah memori | sekitar 70% |
Di sisi lain, TypeScript yang sering diusulkan sebagai jalan tengah memang tidak sound menurut tujuan desainnya sendiri. Anotasi tipe dihapus saat kompilasi ke JavaScript, dan any jadi pintu belakang. Rust tidak memberi pintu itu: tipe yang salah tidak bisa dipaksa lewat, dan Option memaksa pemeriksaan nilai kosong sebelum dipakai.
Contoh yang paling sering dipakai untuk menunjukkan bedanya: 100 thread menambah satu counter. Kalau counter-nya memakai tipe yang hanya aman dalam satu thread, kode Rust tidak akan dikompilasi, dengan pesan bahwa nilai itu tidak aman dikirim antar thread. Di JavaScript, kode serupa bisa berjalan dan hanya sesekali menghasilkan angka yang salah.
Bagian yang hilang dari argumen itu
Semua bukti di atas benar. Yang tidak ikut dihitung adalah ongkos per putaran, padahal di vibe coding putaran itulah satuan kerja yang menentukan.
Compiler memang pengawal gratis dalam arti tidak ada tagihan per jam. Namun ia memakan waktu, dan waktu di dalam loop agen adalah biaya yang dibayar berkali-kali. Tiga hal yang biasanya tidak masuk hitungan:
| Faktor | Kenapa penting |
|---|---|
| Waktu kompilasi | setiap iterasi agen menunggu, tidak hanya sekali di akhir |
| Produktivitas penulis | hanya 53% pengguna Rust merasa produktif menurut survei State of Rust 2024 |
| Data latih | Rust lebih sedikit di data latih model, jadi koreksi lebih sering |
| Kecepatan membangun aplikasi | Rust butuh minggu sampai bulan, Go hitungan hari |
Baris terakhir itu yang paling sering terlewat. Bukan karena Rust sulit, tapi karena setiap putaran koreksi menambah satu putaran lagi. Semakin lambat putarannya, semakin banyak waktu yang dihabiskan untuk menunggu alat yang sama yang seharusnya menghemat waktu.
Go sebagai pembanding
Go tidak memiliki pengawal seketat Rust. Ia memiliki garbage collector yang sesekali berhenti, biasanya di bawah 1 milidetik, dan tidak punya jaminan bebas data race seperti Send dan Sync di Rust.
Yang dimiliki Go adalah putaran yang cepat. Toolchain-nya satu berkas, aturannya sedikit, dan pengembang biasanya produktif dalam hitungan hari, bukan bulan. Untuk sebagian besar aplikasi web, satu server Go sanggup melayani puluhan ribu permintaan per detik di mesin yang tidak mahal.
Perbandingan yang lebih adil untuk kebutuhan vibe coding:
| Aspek | Rust | Go |
|---|---|---|
| Kode salah tetap jalan | hampir tidak mungkin | kadang bisa |
| Kecepatan membuat aplikasi | minggu sampai bulan | hitungan hari |
| Waktu generate dan biaya AI | termahal dan terlama | sedang |
| Performa ekstrem dan latensi ketat | terbaik | baik |
| Jeda garbage collector | tidak ada | di bawah 1 milidetik |
| Jaminan keamanan thread dari compiler | ada | tidak ada |
Jika bottleneck yang kamu hadapi adalah kecepatan tim dalam membuat fitur, Go lebih tepat. Jika bottleneck-nya latensi dan bug memori di produksi, Rust lebih tepat. Dua kalimat itu cukup untuk 80% keputusan, dan sisanya ditentukan oleh seberapa mahal kesalahan pada sistemmu.
Kenapa compile time Rust memang berat
Ini bukan soal tooling yang belum matang. Beban itu lahir dari hal-hal yang membuat Rust aman:
| Penyebab | Efek pada waktu kompilasi |
|---|---|
| Borrow check dan analisis kepemilikan | pekerjaan tambahan sebelum kode jadi |
| Monomorphization generik | kode yang sama dikompilasi ulang untuk tiap tipe konkret |
| Optimasi lewat LLVM | hasil akhir cepat, prosesnya lambat |
| Proc macro | dijalankan sebagai kode saat kompilasi |
| Banyak crate kecil | ratusan unit kompilasi, masing-masing punya biaya |
Go memilih jalan lain: compiler sederhana, siklus build pendek, dan cache yang agresif. Konsekuensinya, Go menerima jeda GC kecil dan jaminan keamanan yang lebih longgar. Itu keputusan desain, bukan kelalaian.
Waktu kompilasi Rust sangat bergantung pada ukuran proyek dan jumlah dependensi. Proyek kosong bisa selesai di bawah 1 detik, sedangkan layanan dengan ratusan crate bisa butuh menit untuk build bersih. Yang perlu kamu ukur adalah proyekmu sendiri, di mesin yang dipakai agen.
Kapan biaya itu tidak masalah
Ada beberapa situasi di mana compile time lambat tidak mengubah apa pun:
| Situasi | Alasan |
|---|---|
| Perubahan jarang, layanan berumur panjang | biaya build dibagi ke bulan pemakaian |
| Build di CI, bukan di mesin pengembang | waktu tunggu tidak dirasakan langsung |
| Kode kritis yang mahal kalau salah | satu bug produksi lebih mahal dari 10 menit menunggu |
| Pustaka inti yang dipakai banyak layanan | dikompilasi sekali, dipakai bertahun-tahun |
Sebaliknya, biaya itu paling terasa saat kamu bekerja di dalam loop: mengubah satu fungsi, menunggu, melihat error, mengubah lagi. Itulah pola kerja vibe coding.
Cara memangkas biaya di Rust
Kalau kamu tetap memilih Rust, beberapa langkah berikut dapat memotong waktu tunggu tanpa mengorbankan jaminan compiler:
BASH# periksa tipe tanpa menghasilkan biner
cargo check
# pisahkan crate yang jarang berubah dari yang sering diedit
# supaya yang dikompilasi ulang hanya bagian kecil
# matikan debug info saat iterasi cepat
CARGO_PROFILE_DEV_DEBUG=0 cargo check
# pakai linker lebih cepat
# .cargo/config.toml
# [target.x86_64-unknown-linux-gnu]
# rustflags = ["-C", "link-arg=-fuse-ld=lld"]
Urutan yang paling berpengaruh biasanya: cargo check alih-alih cargo build, memecah workspace, lalu linker. Menghindari proc macro berat juga membantu, karena macro dijalankan saat kompilasi dan sering menjadi sumber waktu yang tidak terlihat.
Satu hal yang tidak dapat dipangkas: agen tetap harus menunggu hasil pemeriksaan. Yang bisa dipangkas hanya durasinya.
Angka dari uji banding tiga bahasa
Terdapat eksperimen yang membangun API yang sama dalam tiga bahasa dengan bantuan AI, lalu menguji hasilnya:
| Bahasa | Hasil |
|---|---|
| Rust | lulus 23 dari 24 kelompok tes, tidak pernah crash |
| Python | lulus 21 dari 24 kelompok tes |
| TypeScript | gagal sejak awal, migrasi basis datanya tidak jalan |
Hasil itu mendukung argumen bahwa Rust lebih aman. Namun eksperimen yang sama mencatat harga yang dibayar: waktu pembuatan versi Rust sekitar 2 kali versi Python, dengan biaya sampai 42% lebih mahal.
Keduanya benar, hanya membahas hal yang berbeda: satu menilai mutu hasil, satu menghitung biaya proses. Artikel ini menempatkan keduanya pada satu perhitungan.
Matriks keputusan
| Kebutuhan | Pilihan yang masuk akal |
|---|---|
| Prototipe cepat, ide yang belum jelas | Python, TypeScript, atau Go |
| API dan layanan biasa dengan tim kecil | Go |
| Web umum, CMS, toko online | PHP dengan Laravel |
| Produksi kritis, latensi ketat, data pengguna | Rust |
| Pustaka inti yang dipakai banyak layanan | Rust |
Untuk semua pilihan itu, satu hal tetap berlaku: vibe coding butuh pengujian. Setel lint menjadi error, jalankan tes otomatis, dan periksa bagian yang paling mahal kalau salah. Prototipe boleh santai, produksi tidak. Kalau kamu memakai Go, ada kumpulan trik Go untuk kerja harian yang lebih dulu berguna daripada memilih bahasa baru.
Pertanyaan yang menentukan
Sebelum memilih Rust karena compiler-nya menjaga, hitung dulu tiga hal:
- Berapa detik satu putaran pemeriksaan di proyekmu, di mesin yang dipakai agen?
- Berapa putaran yang biasanya dibutuhkan untuk satu fitur?
- Berapa biaya satu bug yang lolos ke produksi dibanding waktu tunggu yang kamu hemat?
Kalau hasil perkalian dua angka pertama masih di bawah biaya satu insiden produksi, Rust pilihan yang tepat. Jika tidak, kamu membayar premi asuransi untuk risiko yang belum tentu terjadi, dengan mata uang termahal: waktu tunggu yang berulang puluhan kali sehari.
Rust bukan pilihan yang salah untuk era vibe coding. Ia pengawal yang menagih biaya di awal, dan biaya itu tidak pernah terlihat di tangkapan layar.
