Rust di Embedded & Kernel: Hype vs Realita Pahit Developer

Key Takeaways:

• Rust di kernel Linux masih sangat awal, hanya subsistem kecil yang sudah di-maintain
• Embedded development dengan Rust terbentur ekosistem toolchain yang belum matang
• Memory safety bukan satu-satunya faktor, real-time constraints dan hardware support jauh lebih krusial

Linus Torvalds pernah bilang Rust adalah bahasa paling menarik dalam dekade terakhir. Kernel Linux 6.1 akhirnya membuka pintu untuk Rust. Media teknologi ramai memberitakan era baru sistem programming. Tapi coba tanya ke engineer yang benar-benar kerja di embedded atau kernel development sehari-hari, jawabannya bakal jauh lebih nuansa.

Artikel ini bukan anti-Rust. Justru karena kita percaya Rust punya masa depan, kita perlu bicara jujur soal gap antara hype yang beredar di konferensi dengan realita pahit di lapangan. Kalau lu sedang evaluasi apakah akan adopt Rust untuk proyek embedded atau kernel, ini peta lengkap yang perlu lu tahu sebelum commit.

Bukan Sekadar “C Plus Safety”

Banyak presentasi memosisikan Rust sebagai “C yang aman”. Framing ini menyesatkan. Rust bukan C dengan borrow checker. Rust adalah bahasa dengan model mental yang sama sekali berbeda.

Di embedded development, lu berurusan dengan:

• Register mapping yang butuh raw pointer access
• Interrupt handlers yang harus deterministic dan super cepat
• Memory-mapped I/O di mana lu literally menulis ke alamat fisik tertentu
• No_std environment tanpa allocator, tanpa standard library

Di sinilah Rust's ownership model jadi pedang bermata dua. Borrow checker yang menyelamatkan lu dari data race di aplikasi server, di embedded justru jadi sumber frustrasi ketika lu perlu shared mutable state untuk interrupt handler.

Kernel Linux: Pintu Terbuka, Tapi Lorong Sempit

Benar bahwa kernel Linux sekarang support Rust. Tapi mari kita lihat apa yang sebenarnya terjadi:

Scope yang diizinkan masih sangat terbatas. Rust di kernel Linux 6.1 hanya untuk driver tertentu. Bukan untuk core kernel. Bukan untuk scheduler. Bukan untuk memory management subsystem. Miguel Ojeda, maintainer Rust di kernel, sendiri sangat konservatif soal apa yang boleh ditulis dalam Rust.

Toolchain dependency jadi nightmare baru. Kernel build system selama ini hanya butuh C compiler. Sekarang lu perlu Rust compiler dengan versi spesifik, Rust bindings untuk kernel, dan semua dependency-nya. Coba jelaskan ke tim infrastructure bahwa mereka perlu manage Rust toolchain versi tertentu di samping GCC dan Clang.

Debugging experience masih primitif. Ketika kernel panic terjadi di code Rust, tooling untuk debug belum se-matang C. GDB support untuk Rust kernel module masih berkembang. Stack trace analysis lebih sulit.

Bicara soal compile time dan toolchain, ini terkait erat dengan masalah yang kita bahas di artikel Rust's Hidden Tax: 3 Pajak Tersembunyi. Compile time yang lama bukan hanya annoyance di server, tapi jadi bottleneck serius di embedded workflow.

Embedded Ecosystem: Kesenjangan yang Jarang Dibahas

Ini bagian yang paling sering hilang dari artikel “Kenapa Rust Cocok untuk Embedded”:

1. HAL (Hardware Abstraction Layer) coverage masih tipis

C punya driver untuk hampir setiap mikrokontroler yang pernah dibuat. STM32, AVR, ESP32, PIC, ARM Cortex-M, semuanya punya library mature. Di Rust, embedded-hal project memang berkembang pesat, tapi coverage-nya masih jauh dari lengkap. MCU baru rilis, C driver sudah ada dalam hitungan minggu. Rust? Bisa bulanan.

2. Build time di resource-constrained environment

Rust compiler terkenal lambat. Di server dengan 32 core dan 64GB RAM, ini annoyance. Di embedded developer laptop dengan resource terbatas, atau di CI pipeline yang build untuk multiple target MCU, ini jadi bottleneck serius.

3. Binary size untuk constrained devices

Meskipun sudah pakai no_std dan panic = "abort", Rust binary untuk embedded masih cenderung lebih besar dibanding C equivalent. Di MCU dengan 256KB flash, setiap kilobyte berarti. Optimasi -C opt-level=z membantu, tapi tidak selalu cukup.

Real-Time Constraints: Area yang Paling Bermasalah

Embedded systems sering punya hard real-time requirements. Response time harus deterministic. Worst-case execution time (WCET) harus bisa diprediksi dan dibuktikan.

Rust's abstraction layers bisa jadi masalah di sini:

• Drop trait yang execute saat variable keluar scope bisa menambah latency yang tidak terduga
• Iterator chains yang elegant di code bisa generate code path yang sulit diprediksi WCET-nya
• Panic handling di Rust default-nya unwind, yang di embedded context bisa catastrophic

C memberikan lu kontrol absolut. Setiap cycle bisa lu akun. Rust memberikan abstraction yang kadang menyembunyikan cost sebenarnya.

Kapan Rust Memang Worth It di Embedded

Jangan salah paham. Ada skenario di mana Rust benar-benar shine:

• IoT gateway yang jalankan Linux embedded, bukan bare metal MCU
• Device dengan network stack kompleks di mana memory safety critical
• Firmware update mechanism yang butuh crypto verification dan rollback protection
• Edge computing node yang jalankan aplikasi level tinggi di atas OS

Di skenario ini, Rust's safety guarantees benar-benar bernilai. Network-facing code yang deal dengan untrusted input adalah use case ideal. Tapi ini bukan “embedded” dalam artian mikrokontroler resource-constrained.

Kalau lu penasaran kapan waktu tepat untuk mulai migrasi ke Rust, cek artikel Migrasi Rust: Siapa yang Pindah, Siapa yang Nggak untuk panduan lebih lanjut.

Framework Evaluasi: 5 Pertanyaan Sebelum Adopt

Sebelum lu putuskan adopt Rust untuk proyek embedded atau kernel, jawab lima pertanyaan ini dengan jujur:

1. Apakah tim lu punya bandwidth untuk learning curve 6-12 bulan?
Rust bukan bahasa yang bisa dikuasai dalam weekend. Borrow checker akan melawan intuisi yang sudah terbangun bertahun-tahun pakai C. Estimasi konservatif: 6 bulan untuk productive, 12 bulan untuk confident.

2. Apakah hardware target punya Rust support yang mature?
Cek embedded-hal crate untuk MCU lu. Cek apakah ada board support package (BSP) yang maintained. Kalau tidak ada, lu akan jadi pioneer, dan pioneer dapat panah duluan.

3. Apakah real-time requirement lu hard atau soft?
Hard real-time dengan deadline mikrodetik? Rust mungkin bukan pilihan terbaik saat ini. Soft real-time dengan margin longgar? Rust bisa kerja.

4. Apakah lu build untuk production atau proof-of-concept?
PoC dengan Rust? Silakan, belajar sambil eksperimen. Production firmware yang akan di-deploy ke 10.000 device? Pertimbangkan matang-matang.

5. Apakah ada regulatory requirement?
Industri automotive (ISO 26262), medical (IEC 62304), aerospace (DO-178C) punya certification requirement. Rust toolchain certification masih sangat awal. C compiler seperti GCC dan LLVM sudah punya track record certification yang panjang.

Masa Depan: Optimis Tapi Realistis

Rust di embedded dan kernel bukan soal “if” tapi “when”. Tren jelas mengarah ke adoption yang lebih luas. Android sudah pakai Rust untuk sistem components baru. Microsoft juga mulai adopt Rust untuk Windows kernel components.

Tapi “when” bukan “now”. Gap antara hype dan realita masih lebar. Toolchain akan matang. Ecosystem akan tumbuh. Debugging experience akan membaik. Tapi hari ini, di tahun 2025, lu perlu membuat keputusan berdasarkan realita saat ini, bukan visi 5 tahun ke depan.

Kalau lu evaluator yang rasional, pendekatan terbaik adalah incremental adoption. Mulai dari komponen yang paling benefit dari memory safety: network stack, parser, cryptographic implementation. Biarkan C handle bagian yang butuh kontrol absolut: interrupt handler, register-level programming, real-time critical path.

Rust bukan replacement untuk C di embedded. Rust adalah complement. Mengerti kapan pakai yang mana adalah skill yang lebih berharga daripada fanatisme buta ke satu bahasa.

Punya pengalaman nyata pakai Rust di embedded atau kernel development? Share di komentar. Cerita dari lapangan jauh lebih berharga daripada teori dari menara gading.