Ulasan Bahasa Pemrograman Rust: Apakah Layak Dipelajari?

Tanyakan kepada dua developer Rust berpengalaman apakah belajar Rust sepadan dengan usahanya, dan kamu bisa mendapat jawaban yang sepenuhnya bertolak belakang. Yang satu mungkin bilang Rust tidak berpengaruh apa pun pada kariernya; yang lain mungkin menyebutnya salah satu keputusan teknis terbaik yang pernah ia buat. Keduanya bisa sama-sama benar.

Di kontradiksi itulah pertanyaan “apakah Rust layak dipelajari” sebenarnya berada, dan itu sebabnya jawaban “ya” yang pukul rata tidak berguna bagimu. Rust adalah bahasa terkompilasi yang subset amannya menegakkan aturan keamanan memori saat kompilasi, tanpa memerlukan garbage collector saat runtime.

Jadi saya akan berkomitmen pada satu jawaban, menyebutkan syarat yang menjadi gantungannya, dan menunjukkan berapa harga syarat itu.

Versi Singkat

Rust layak dipelajari jika kamu sedang membangun sesuatu yang berumur panjang, di mana compiler yang menangkap satu kelas bug layak dibayar. Rust pilihan yang salah jika kamu perlu merilis aplikasi CRUD bulan ini, sedang belajar memprogram, atau sedang menghitung lowongan kerja. 4 dari 5, dikurangi karena biayanya datang sebelum hasilnya.

• Yang kamu beli: di Rust yang aman, aturan ownership dan borrowing mengubah bug use-after-free, double-free, referensi tidak valid, dan data race menjadi error saat kompilasi, bukan insiden di produksi. Itulah seluruh tawarannya, dan itu tawaran yang bagus.
• Yang kamu bayar: compiler memaksamu menuliskan keputusan memori yang dibuat diam-diam oleh bahasamu saat ini, dan di awal itu terasa seperti alatnya sedang mempersulit.
• Soal daya tahan sudah selesai. Para maintainer kernel menyimpulkan eksperimen Rust di Maintainers Summit Desember 2025, dan label “eksperimental” dicopot di Linux 7.0.
• Soal tren belum selesai, dan itu pertanyaan yang berbeda. Rust berada di #10 pada indeks TIOBE September 2026, naik dari #18 setahun sebelumnya.
• Layanan Rust uji saya butuh memori jauh lebih banyak untuk dikompilasi daripada untuk dijalankan: puncaknya sekitar 1 GB saat build dan diam di sekitar 3,5 MB saat berjalan.
• Cocok untukmu jika kamu sudah merilis produk dengan bahasa lain dan sedang membangun sesuatu di mana bug memori akan mahal, atau kamu bekerja dekat perangkat lunak sistem. Tidak cocok untukmu jika kamu dikejar tenggat, mulai dari nol, atau sedang mencari bahasa dengan lowongan terbanyak.

Cara ulasan ini dibuat: angka build dan runtime di sini adalah hasil saya sendiri. Saya memasang Rust 1.98.1, menulis layanan web Axum kecil, dan mengukur apa yang dibutuhkan untuk mengompilasi dan menjalankannya. Itu berjalan di container sandbox, bukan di hardware khusus, dan hanya satu proyek, jadi anggap angkanya sebagai satu titik data, bukan hukum. Selebihnya berasal dari sumber primer atau otoritatif: patch kernel dan liputan LWN tentangnya, postingan keamanan Android dari Google, indeks TIOBE sendiri (dengan komentar April melalui catatan Slashdot), Phoronix tentang merge window Linux 7.0, catatan CVE kernel Linux untuk kerentanan Binder, pernyataan Canonical sendiri, dan survei Stack Overflow 2025. Saya membaca patch kernel-nya. Saya tidak mengaudit kode Rust di kernel. Dan saya belum bertahun-tahun menulis Rust, jadi di bagian ulasan ini yang menilai bahasanya sendiri, saya bersandar pada praktisi yang sudah bertahun-tahun menulisnya, dan menyebut nama mereka.

Apa yang Dibelikan Compiler untukmu

Berikan dua thread referensi mutable ke vector yang sama di Rust, dan kodenya tidak akan terkompilasi. Bukan peringatan. Bukan lint yang bisa kamu matikan saat dikejar tenggat. Kodenya tidak ter-build. Penolakan itulah yang kamu beli di Rust yang aman: bug use-after-free, double-free, referensi tidak valid, dan data race didorong menjadi error kompilasi, bukan insiden di produksi. Pintu darurat Rust (unsafe) bisa melewati sebagian jaminan itu, jadi ini bukan janji mutlak untuk setiap codebase Rust.

Ownership berarti setiap nilai punya tepat satu pemilik yang bertanggung jawab melepaskannya. Borrowing berarti kamu bisa meminjamkan referensi, tetapi compiler melacak lifetime-nya dan tidak akan membiarkan satu referensi hidup lebih lama dari yang ditunjuknya, atau membiarkan borrow mutable ada bersamaan dengan borrow lain. Di Rust yang aman, bug use-after-free, double-free, referensi tidak valid, dan data race ditangkap oleh sistem ownership dan tipe sebelum program berjalan.

Tidak ada garbage collector, dan itu separuh lain dari kesepakatannya. Karena ownership sudah menentukan siapa membebaskan apa dan kapan, tidak ada yang perlu menelusuri heap-mu saat runtime. Kamu merilis binary tanpa collector di dalamnya, dan tidak ada waktu jeda yang harus kamu akali.

Harganya muncul di tempat yang sama dengan jaminannya. Setiap keputusan memori yang dibuat diam-diam oleh bahasamu saat ini atas namamu adalah keputusan yang diminta Rust untuk kamu tuliskan: siapa pemilik ini, berapa lama referensi itu hidup, apakah ada hal lain yang bisa melihatnya, dan apakah ia melintasi batas thread. Compiler-nya tidak sedang mempersulit. Ia menolak menebak.

Jadi: inilah alasan orang mau membayar apa yang diminta Rust, dan menurut saya alasan ini bertahan. Jika kelas bug yang dihilangkannya bukan kelas yang kamu khawatirkan, sisa ulasan ini kemungkinan besar tidak akan mengubah pikiranmu.

Apakah Rust Masih Eksperimental, atau Sudah Jadi Infrastruktur Produksi?

Rust berhenti menjadi eksperimental pada Desember 2025, dan yang mengakhirinya adalah para maintainer kernel sendiri. Di Maintainers Summit 2025 mereka menyimpulkan bahwa Rust telah membuktikan dirinya di kernel, secara teknis maupun sosial. Jonathan Corbet dari LWN melaporkan konsensus itu pada 10 Desember 2025: Rust di kernel tidak lagi eksperimental.

Rust masuk ke Linux mainline di v6.1 pada 2022 khusus untuk menjalankan eksperimen itu. Patch Miguel Ojeda yang mencopot label tersebut menyusul tiga hari setelah Summit, dan masuk untuk merge window Linux 7.0.

“Tapi eksperimennya sudah selesai, artinya Rust akan tetap ada.”

Miguel Ojeda, “rust: conclude the Rust experiment”, LKML, 13 Desember 2025

Terpisah, dan lebih awal: penulisan ulang driver Binder Android dengan Rust oleh Google, lapisan IPC tempat proses-proses Android berkomunikasi (terus-menerus), masuk ke Linux 6.18, yang dirilis pada 30 November 2025. Pisahkan tonggak ini dari konsensus Summit. Inilah momen ketika sebuah perusahaan mempertaruhkan produk yang sudah dikirim ke pengguna pada Rust di kernel, bukan sekelompok maintainer yang merestui idenya. Rust di kernel sejak itu telah menghasilkan CVE pertamanya: CVE-2025-68260, sebuah race condition di driver Binder yang sama yang diumumkan Greg Kroah-Hartman pada 16 Desember 2025, muncul di 6.18 dan diperbaiki di 6.18.1. Laporan awal berfokus pada crash, tetapi penilaian tim CVE kernel Linux yang lebih baru memberi CVE-2025-68260 skor 7,8 (Tinggi) dan menggambarkan jalur eskalasi hak akses lokal melalui korupsi memori kernel. Driver yang sama (rust_binder) juga telah mengumpulkan CVE tambahan sejak itu.

Android adalah tempat buktinya menjadi angka. Blog keamanan Google menyatakan pada Desember 2022 bahwa ada nol kerentanan keamanan memori yang ditemukan di kode Rust Android, dari sekitar 1,5 juta baris Rust di AOSP dan sekitar 21% dari seluruh kode native baru di Android 13. Itu pernyataan tahun 2022 dengan cakupan 2022. Postingan Google berikutnya memberi tren yang lebih panjang: masalah keamanan memori menyumbang 76% kerentanan Android pada 2019 dan 24% pada 2024, dengan jumlah mentahnya turun dari lebih dari 220 menjadi proyeksi 36. Angka-angka itu hanya bermakna jika dibandingkan dengan baseline yang digantikannya, yaitu C dan C++ yang ditulis oleh engineer yang sangat bagus dengan tooling yang sangat bagus.

Dua sinyal yang lebih kecil menunjuk ke arah yang sama. Driver GPU Apple AGX di Asahi Linux ditulis dengan Rust, oleh proyek Asahi Linux sebagai upaya reverse engineering, bukan oleh Apple. Pembaruan rust-coreutils dari Canonical menyebutkan bahwa Ubuntu 26.04 LTS menyertakan rust-coreutils 0.8.0 untuk sebagian besar utilitas. Tiga tetap memakai GNU coreutils (cp, mv, rm) karena delapan masalah TOCTOU masih terbuka per 22 April 2026; Canonical menargetkan 26.10 untuk utilitas yang tersisa.

Inilah sumbu yang saya beri nilai tertinggi, dan alasannya adalah jenis komitmen yang terlibat. Maintainer kernel tidak membatalkan kesimpulan eksperimen, Google tidak membatalkan penulisan ulang sebesar itu, dan Canonical tidak memasukkan coreutils hasil tulis ulang ke rilis LTS hanya untuk coba-coba. Apa pun yang terjadi pada popularitas Rust, seseorang harus memelihara kode itu selama bertahun-tahun.

Apakah Rust Sudah Mati, atau Hanya Mendatar?

Tidak. Rust menyamai posisi terbaiknya sepanjang masa di TIOBE, #13, pada Januari 2026. Tiga bulan kemudian ia turun kembali ke #16, dan CEO TIOBE Paul Jansen menulis pada April 2026, dalam komentar yang dikutip Slashdot saat itu, bahwa pertumbuhan popularitas Rust “tampaknya mulai mendatar” dan bahwa posisi 10 besar “kini tampak lebih jauh dari sebelumnya.”

Ia sedang menggambarkan Rust mencapai posisi tertingginya sepanjang masa di indeksnya sendiri, posisi yang pertama kali diraihnya pada Juli 2024, lalu melepaskannya lagi.

Indeks TIOBE September 2026 menempatkan Rust di #10, naik dari #18 setahun sebelumnya, dan melewati #13 yang disebut TIOBE sebagai posisi tertingginya sepanjang masa pada Januari.

Pendapat saya: plateau itu nyata. Itu kantong udara, bukan plafon. Itu lebih tepat daripada versi kedua kubu, karena “Rust mandek” sekarang salah dan “Rust hanya bisa naik” memang tidak pernah benar.

Catatan kehati-hatiannya berlaku ke dua arah, dan tulisan Slashdot mengangkatnya saat itu: mungkinkah peringkatnya hanya berfluktuasi karena noise bulanan pada hasil mesin pencari, yang memang dihitung oleh indeks itu? Jika turun tiga posisi dalam satu kuartal adalah bukti tipis bahwa Rust melambat, naik enam posisi juga bukti tipis bahwa ia menang. Anggap saja cuaca, bukan iklim.

Sinyal sentimen yang lebih kuat adalah survei Stack Overflow, di mana Rust sekali lagi menjadi yang paling dikagumi sebagai bahasa pemrograman pada 2025 dengan 72%: orang-orang yang memakainya setahun terakhir dan ingin terus memakainya. Itu niat untuk terus memakai, bukan adopsi, dan di sini sinyal itu lebih berguna daripada popularitas mentah jika kamu sedang memutuskan apakah akan betah bertahan dengan bahasa ini.

Momentumnya ambigu, dan saya memberinya bobot di bawah daya tahan di atas, karena kamu tidak sedang berinvestasi pada sebuah peringkat.

Berapa Biaya Belajar Rust bagimu

Biayanya datang di awal dan sekaligus. Kode yang dengan senang hati dijalankan Python, Java, atau C# ditolak, berulang kali, karena alasan yang terasa sewenang-wenang sampai model ownership-nya klik, dan tidak ada cara untuk menundanya. Kamu tidak bisa melewati borrow checker dengan terus merilis kode seperti kamu bisa terus merilis meski belum sepenuhnya memahami ORM-mu.

Ini bagian yang mengejutkan saya, dan arahnya berlawanan dengan yang kamu kira. Di thread r/rust “Struggling to learn Rust”, balasan yang paling banyak mendapat perhatian membingkai ulang masalahnya sebagai ketidakbiasaan, bukan kesulitan, dan thread itu menunjuk developer berpengalaman yang datang dari bahasa ber-garbage collector sebagai pihak yang paling kesulitan. u/Voxelman mengatakannya dengan lugas: “Rust itu tidak sulit. Rust itu berbeda.” Di thread yang sama ia menceritakan jalannya sendiri: C64 Basic, lalu berbagai bahasa imperatif, dan kontak pertama dengan Rust yang “sama sekali tidak WOW” karena melepas kebiasaan lama butuh waktu.

Itulah bentuk tagihannya. Jika kamu sudah menulis Python selama delapan tahun, kamu tidak sedang mempelajari seperangkat aturan, kamu sedang melepaskan seperangkat asumsi tentang siapa yang membereskan di belakangmu. Orang yang tahu lebih sedikit punya lebih sedikit yang harus dilupakan.

Satu pola lagi muncul berulang kali di thread itu, dan pola ini mengubah kesalahan urutan menjadi masalah kepercayaan diri: orang terjebak bukan di Rust, melainkan saat memilih framework web, mencoba belajar bahasanya lewat Axum atau Actix sebelum konsep ownership meresap. Seperti kata u/jmartin2683, itu “seperti mencoba belajar ruby dengan belajar rails.”

Menurut saya sebagian besar peringatan soal biaya ini menunjuk ke hal yang salah. Siapkan latihan yang konsisten, bukan satu akhir pekan, dan jangan anggap frustrasi awal sebagai vonis atas kemampuanmu.

Rust Butuh Mesin Lebih Besar untuk Build daripada untuk Menjalankannya

Ini temuan yang tidak saya duga: mem-build proyek Rust ini butuh memori berlipat-lipat kali lebih banyak daripada menjalankannya. Saya mem-build layanan Axum kecil (Tokio dengan fitur full aktif, serde, serde_json, tower, satu route JSON, sekitar 60 crate di dependency tree) di rustc dan cargo 1.98.1, dengan strip = true di profil release, lalu mem-build-nya dari keadaan bersih dua kali:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Dengan dibatasi satu job kompilasi (--jobs 1), puncak memori di cargo, rustc, dan linker berada di antara 464 MB dan 527 MB tergantung metode pengukuran mana dari dua metode saya yang kamu pakai (saya mengukurnya dua cara karena angka pertama terlihat terlalu rapi), dan build-nya memakan 113 detik. Dengan paralelisme default di empat vCPU, puncak memori kira-kira berlipat dua menjadi sekitar 1 GB dan build selesai dalam sekitar 35 detik. Variabelnya di sini adalah paralelisme, bukan proyeknya. Lebih banyak job berarti lebih banyak proses rustc yang tinggal di memori sekaligus, dan itulah sebabnya compiler termasuk sedikit workload yang akan dengan senang hati memakai setiap core yang kamu berikan selama bermenit-menit tanpa henti.

Program jadinya berukuran 1,3 MB setelah di-strip, dan saat diam memakai sekitar 3,3 hingga 3,6 MB memori.

Pada paralelisme default, itu dua sampai tiga ratus kali lebih banyak memori untuk mengompilasi daripada untuk menjalankan; dibatasi satu job pun masih jauh di atas seratus kali. Ukur server sesuai kebutuhan layanan Rust-mu di produksi dan kamu bisa berakhir dengan mesin yang tidak mampu mem-build-nya, dan mode kegagalannya bukan error yang rapi: yang terjadi adalah OOM killer mematikan rustc di tengah build, atau compiler yang menghajar swap selama dua puluh menit. Ada dua jawaban yang berhasil. Build di tempat yang punya ruang lega lalu kirim binary-nya, pola yang sama seperti memisahkan mesin build tersendiri untuk pekerjaan Docker yang berat. Atau build di mesin itu dan beri ruang: untuk layanan dengan bentuk seperti ini, beberapa gigabyte RAM dan dua vCPU sudah nyaman. Jika belum cukup, pintu daruratnya adalah --jobs 1 (ya, lebih lambat; itulah kompromi yang harus dibayar).

Jika mesin tempat kamu bekerja tidak punya ruang lega itu, Linux VPS self-managed kami memberimu akses root dengan tagihan per jam atau bulanan dan tempat untuk menaruh build lalu mengembalikannya setelah selesai, meski tetap saja itu server yang kamu kelola, bukan server yang mengelola dirinya sendiri.

Satu proyek, satu bentuk, satu mesin. Mesinnya adalah container sandbox bersama, bukan server dedicated, dengan sekitar 2 GB memori tersedia, jadi puncak tanpa batas itu berjalan lebih dekat ke plafonnya dibanding di mesin yang lebih besar. Ini bukan konstanta universal: jika dependency tree-mu empat kali lebih besar atau profil release-mu mengaktifkan link-time optimization, harapkan angka yang berbeda. Dependency tree yang lebih besar, link-time optimization, dan kode yang banyak memakai generic bisa mendorong memori build lebih tinggi, jadi jangan anggap pengukuran saya sebagai plafon universal.

Saya menggolongkan ini ke soal cara kamu bekerja, bukan soal apakah kamu belajar bahasanya. Ketahuilah sebelum kamu mengalaminya.

Siapa yang Sebaiknya Belajar Rust

Tiga situasi di mana saya akan menyuruhmu meluangkan waktu: perangkat lunak berumur panjang di mana bug memori itu mahal, pekerjaan yang dekat dengan sistem operasi, dan keinginan mendapatkan efek dari bergulat dengan compiler terhadap cara berpikirmu soal memori. Masing-masing punya alasan mengapa waktu itu terbayar kembali.

Kamu sudah merilis produk dengan bahasa lain dan sedang membangun sesuatu yang berumur panjang di mana bug memori akan mahal. Layanan yang harus tetap hidup. Library yang diandalkan tim lain. Apa pun di mana use-after-free berarti review insiden, bukan sekadar stack trace di terminalmu. Inilah kasus yang menjadi tujuan seluruh jaminan itu dibangun, dan apa yang kamu bayar di awal teramortisasi sepanjang umur hal yang kamu bangun.

Kamu bekerja di dekat atau di dalam perangkat lunak sistem. Driver, pekerjaan perangkat, utilitas sistem dasar, embedded, apa pun yang berada di bawah sistem operasi alih-alih di atasnya. Industri sudah berkomitmen di sini dengan cara yang belum terjadi di tempat lain, dan bukti keamanan memorinya paling kuat di sini.

Kamu menginginkan efek sampingnya. Dua komentator di thread r/rust itu sepenuhnya berbeda pendapat soal nilai Rust bagi karier, tetapi sampai di titik yang sama di sini. u/tyler_church, yang bilang Rust tidak berdampak apa pun pada kariernya, tetap mengakui “mungkin ada pengaruh halus pada cara saya menulis program lain dalam bahasa lain.” u/SirKastic23, yang sudah dua tahun dibayar untuk menulis Rust, mengatakan Rust memperluas keterampilan coding-nya dengan cara yang tidak pernah ia duga. Dua orang, bukan sebuah studi, tetapi inilah manfaat yang tetap ada meski kamu tidak pernah menulis Rust secara profesional: perubahan dalam cara berpikirmu, bukan satu baris di CV.

Siapa yang Sebaiknya Tidak Belajar Rust

Tiga situasi di mana waktu itu lebih baik dipakai untuk hal lain: kamu punya tenggat bulan ini, kamu baru belajar memprogram, atau kamu memilih bahasa berdasarkan berapa banyak lowongan kerja yang menyebutnya. Yang ketiga paling sering ditanyakan.

Kamu punya tenggat bulan ini untuk aplikasi CRUD atau prototipe. Rust datang dengan jadwal yang benar-benar salah untuk pekerjaan yang harus sudah ada hari Jumat. Go adalah pilihan yang jelas sebagai gantinya jika kamu mau bahasa terkompilasi dengan build cepat dan manajemen memori ber-garbage collector, dan tidak butuh jaminan berbasis ownership milik Rust.

Kamu baru belajar memprogram sama sekali. Yang satu ini benar-benar memecah orang yang menulis Rust untuk mencari nafkah, dan perbedaan pendapat di thread r/rust berjalan ke dua arah, jadi posisi saya: menyodorkan lemparan koin kepada pemula adalah saran buruk, ke sisi mana pun koinnya jatuh. Pelajari cara kerja mesin di tempat yang lebih pemaaf dulu, lalu kembali dan biarkan compiler mengencangkannya.

Kamu memilih bahasa berdasarkan berapa banyak lowongan kerja yang menyebutnya. Saya tidak akan memberimu angka di sini, karena saya tidak menemukan angka gaji atau lowongan untuk Rust yang bisa dilacak ke sumber yang berani saya pertahankan. Yang digambarkan u/crusoe di thread r/rust itu adalah pasar dengan posisi yang lebih sedikit dan lebih terspesialisasi. Itu satu komentator di satu thread, bukan data pasar kerja, jadi saya tidak akan menjadikannya klaim bahwa lowongan Rust langka secara umum. Jika jumlah lowongan adalah faktor penentumu, cek lowongan terkini di pasar targetmu sebelum memilih bahasa.

Pertanyaan yang Sering Diajukan