Sudah 10 Tahun Bertaruh pada Rust, dan Apa yang Saya Nantikan ke Depan

• Tulisan yang merangkum pengalaman 10 tahun mengadopsi Rust di pekerjaan nyata sejak tepat setelah rilis Rust 1.0, serta harapan untuk 10 tahun ke depan
• Pada masa awal, masalah kompatibilitas versi, waktu build, dan adaptasi dengan borrow checker terasa sulit
• Komunitas dan ekosistem Rust berkembang pesat berkat “sense pemrograman yang luar biasa” dan budaya komunitas yang kuat, dengan kecenderungan menonjol bahwa banyak developer hebat berkumpul di Rust
• Kini Rust telah menjadi “pilihan yang aman” untuk sistem umum dan backend, dan ketidakpastian telah jauh berkurang berkat perkembangan standard library dan makin matangnya ekosistem crate
• Tulisan ini memaparkan secara konkret tantangan yang masih harus diselesaikan Rust dan arah pengembangannya, seperti kecepatan build, portabilitas, fitur const, konkurensi, dan perluasan ke berbagai domain
• 10 tahun ke depan diperkirakan akan menghadirkan kompilasi yang lebih cepat, perluasan ke lebih banyak domain, dan inovasi dalam pengalaman developer, serta diharapkan loop umpan balik positif ekosistem Rust akan semakin cepat

---

• Pada Juni 2015, sekitar sebulan setelah euforia peluncuran Rust 1.0 mulai mereda, penulis menulis kode Rust pertamanya
• Setelah sebelumnya menggunakan C, Python, dan JavaScript lalu mengenal Rust, penulis tidak pernah menoleh ke belakang lagi
• Berdasarkan pengalaman di dua startup berbasis Rust dan menulis lebih dari 500 ribu baris kode, penulis membagikan refleksi selama 10 tahun

Masa awal itu berat - The early days were painful

• Saat awal mengadopsi Rust, kompatibilitas versi antara crate dan compiler sangat tidak stabil, dan bahkan untuk perbaikan bug kecil sering kali seluruh lingkungan build harus dipaksa ikut diperbarui
• Konsep borrow checker dan pengelolaan lifetime terasa sulit, dan masalah waktu kompilasi yang meningkat tajam seiring makin kompleksnya tipe menjadi persoalan serius
• Setiap kali membutuhkan fitur baru atau bug fix, harus memperbarui “semua versi di dunia”, dan banyak waktu habis untuk mencari kombinasi versi yang kompatibel

Keunggulan komunitas Rust - The people were and are exceptional

• Ekosistem Rust dibangun di atas budaya pemrograman yang luar biasa, yang mengutamakan implementasi yang sederhana dan elegan, serta performa yang cepat dan kokoh
• Dibanding saat memakai TypeScript atau Python, struktur dependensi Rust jauh lebih rapi dan build-nya lebih sederhana
• Kontribusi penuh dedikasi dari relawan komunitas serta sikap hati-hati “bukan sekarang/belum saatnya” memainkan peran kunci
• Di London, merekrut developer Rust menjadi keuntungan besar, dan kemampuan rata-rata developer Rust sangat tinggi

Rust telah menjadi pilihan aman (di beberapa domain) - Rust has become a safe bet (in some domains)

• Pada masa awal, karena kekurangan standard library (std), developer harus membuat sendiri fungsi utilitas dan patch, tetapi sekarang sebagian besar fungsi sudah tersedia di std dan crate sehingga ketidakpastian jauh berkurang
• Prediktabilitas build dan upgrade, berkurangnya dependensi eksternal, kepatuhan terhadap semver, serta peningkatan borrow checker dan mesin inferensi membuat pengalaman memakai Rust jauh lebih stabil
• Crate baru seperti jiff, polars, dan tauri dibangun berdasarkan pelajaran dari masa lalu, sementara tokio, hyper, regex, dan lainnya sudah teruji di dunia nyata
• Dulu “menciptakan ulang roda” nyaris tak terhindarkan, tetapi sekarang developer bisa fokus pada business logic dan membangun aplikasi yang cepat serta kokoh

Lingkungan pengembangan yang ditunjukkan Rust saat ini - Rust today feels like what programming should be

• Rust adalah bahasa yang menunjukkan empati terhadap programmer, dengan sistem build yang ringkas dan kokoh, error message dan lint terbaik, dokumentasi dan integrasi IDE yang sangat baik, serta CI dan regression testing yang kuat
• Di antara proyek open source skala besar, jarang ada bahasa yang se-ramah Rust terhadap programmer
• Investasi jangka panjang dari banyak komunitas dan kontributor adalah faktor inti yang membentuk Rust seperti sekarang

Harapan untuk 10 tahun ke depan - What I’m looking forward to over the next 10 years

Build yang lebih sederhana dan lebih cepat - Simpler and faster builds

• Diharapkan upaya untuk mengganti dependensi yang rumit atau lambat dengan yang lebih sederhana dan lebih cepat akan terus berlanjut
• Diharapkan muncul lebih banyak eksperimen baru seperti standard library Rust murni, pengurangan ketergantungan pada system linker dan library, kriptografi pure-Rust, BTreeMap persisten, dan game engine berbasis Rust
• Di Tably, dalam beberapa bulan terakhir kecepatan kompilasi frontend/backend meningkat 60%

Portabilitas yang lebih baik dan lebih sedikit #[cfg()] - Improved portability and less #[cfg()]

• Sulit menguji berbagai kombinasi platform/opsi, dan #[cfg()] menimbulkan masalah seperti kode yang tidak teruji, dokumentasi yang tidak lengkap, dan gangguan pada IDE
• Dengan memindahkan #[cfg()] ke dalam trait system, diharapkan bisa mewujudkan jaminan platform/opsi, minimisasi recompilation, cache MIR, dan CI yang lebih cepat

Semoga semua kode bisa menjadi const - Everything being const

• Dengan melakukan lebih banyak pekerjaan di compile time, ketergantungan pada macro/build script bisa dikurangi dan error runtime juga bisa dicegah lebih awal
• Saat ini masih terbatas, tetapi ke depan Rust diarahkan menuju “semua kode dapat dijalankan dalam const context”

Penyederhanaan konkurensi - Simpler concurrency

• Model async Rust saat ini memiliki kompleksitas tinggi seperti static bound, cancellation-safety, dan pembatasan trait, sehingga menyulitkan penggunaan di dunia kerja
• Seperti user-space green thread (libgreen) di masa lalu, dibutuhkan pendekatan konkurensi yang sederhana di level bahasa

Menjadi unggul di lebih banyak domain - Excelling in more domains

• Area pemanfaatan Rust di dalam web browser (terutama wasm/rustwasm) masih belum sepenuhnya tergarap, dan masih ada berbagai tantangan seperti stack trace lintas browser
  • Framework seperti leptos dan sycamore terus berkembang, tetapi masih ada ruang untuk perbaikan
• Untuk rapid prototyping, business logic, GUI, machine learning, game development, dan domain lain yang belum sepenuhnya ditembus Rust, diharapkan peningkatan akan terus berlangsung

Kesimpulan

• Masa depan pertumbuhan Rust sangat jelas dan penuh harapan
• Semakin luas adopsinya, semakin besar kapasitas engineering dan testing yang terkumpul, yang kemudian membentuk siklus baik berupa adopsi dan perbaikan yang lebih luas
• Dalam 10 tahun mendatang, kompilasi yang lebih cepat, penerapan di berbagai bidang, dan pengalaman pengembangan yang mulus akan semakin menjadi kenyataan
• Penulis menantikan 10 tahun baru bagi Rust

[ndrgrd]

Rust memang punya banyak kelebihan, tetapi bahasanya menuntut terlalu banyak.
Saat menggunakan Rust, rasanya saya lebih banyak mempelajari bahasa Rust itu sendiri daripada fokus pada implementasi ide.

Mungkin tidak ada kendala besar untuk memindahkan proyek yang sudah ada, misalnya dari C++,
tetapi saya kurang yakin apakah nyaman menggunakannya saat mengimplementasikan ide baru.

[felizgeek]

Saya merekomendasikan Python untuk prototyping.

[ndrgrd]

Secara pribadi saya menyukai sistem tipe, jadi saat ini saya menggunakan C# dan merasa tingkat ini sudah cukup memuaskan.

[codemasterkimc]

Secara pribadi, kalau memikirkan lingkungan bumi, pilih RUST. Kode Spring lama diubah ke Axum!!!

[GN⁺]

Komentar Hacker News

• Ini tulisan yang sangat positif dan juga sangat sesuai dengan pengalaman saya. Namun, jika harus menyebut prospek yang suram, bagian ini yang saya pikirkan:
  "async memiliki biaya kompleksitas yang relatif tinggi karena static bound, keamanan pembatalan, serta keterbatasan terkait trait dan dyn. Saat ini belum terlihat tanda-tanda bahwa masalah ini akan terpecahkan. Percabangan antara primitif sinkron/asinkron dan karakteristik unik ekosistem menaikkan async tax (biaya tambahan). Solusi berbasis Effects juga tidak terlalu menjanjikan."
  "Pada Rust sebelum 1.0 ada solusi bernama libgreen. Itu mengimplementasikan konkurensi di user space tanpa bifurcation (pemisahan), tetapi karena biaya performa, portabilitas, dan pemeliharaan cukup besar, akhirnya dihapus. Menurut saya, kalau kapasitas engineering-nya cukup, ini layak dipertimbangkan lagi. Suatu hari saya ingin membuat PoC yang melakukan zero-cost wrapping untuk std::{fs, net} dan fiber::{spawn, select} dengan generator"
  • Saya berpendapat bahwa diskusi seperti "'static bound meningkatkan kompleksitas" hanyalah pilihan desain dari runtime async Tokio, dan sulit melihatnya sebagai desain Rust secara keseluruhan. Runtime async Embassy bisa berjalan tanpa bound seperti itu, tetapi sebagai gantinya pinning harus dikelola secara langsung. 'static bound sebenarnya dimaksudkan untuk mengurangi kompleksitas
• Sebagai orang yang mulai mendalami Rust pada akhir 2022, kisah pengalaman dari mereka yang mempelajari bahasa ini pada masa yang lebih sulit seperti 2015 selalu menarik. Saya merasa beruntung bisa belajar Rust saat sudah lebih matang, sehingga learning curve yang memang curam terasa agak lebih ringan. Belakangan ini, saya merasa sedang mengalami lagi kisah-kisah masa awal Rust yang disebut di tulisan itu, tetapi kali ini lewat Zig. Zig tampaknya berada di fase yang mirip dengan masa awal Rust. Meski begitu, saya sudah memakainya dengan senang
  • Budaya "tinggalkan dalam kondisi yang lebih baik daripada saat ditemukan" sangat kuat. Ada pemahaman bahwa kalau tool atau bahasa terasa membingungkan, itu bukan kesalahan pengguna. Jika saya mengalami kebingungan, orang lain kemungkinan juga akan mengalaminya, jadi memperbaikinya setiap kali ditemukan memberi manfaat besar bagi semua orang. Peribahasa bahwa waktu terbaik kedua untuk menanam pohon adalah hari ini sangat relevan. Berkat budaya ini, seseorang yang dulu mencoba Rust lalu frustrasi bisa saja mendapatkan pengalaman yang jauh lebih baik setahun kemudian. Karena itu, nasihat terbaik untuk pemula Rust dulu adalah "tunggu saja 6 bulan"
  • Jika sebuah bahasa diadopsi oleh big tech seperti MSFT, Google, atau proyek open source besar seperti Linux, itu sudah menjadi bukti bahwa ekosistemnya cukup matang. Namun saya belum punya keyakinan yang sama terhadap Zig, karena sejauh ini ia belum menunjukkan perubahan (besar) dibandingkan tool yang sudah ada
• Saya merasa Rust mendorong pemrograman fungsional. Awalnya saya mencoba membuat parser yang mengubah state internal setiap kali advance, tetapi karena mutability dan sistem borrowing hal itu menjadi sulit, jadi saya terpaksa mengubahnya menjadi parser stateless. Alih-alih memodifikasi indeks internal, strukturnya diubah agar mengembalikan indeks. Saya penasaran apakah kasus seperti ini, ketika pendekatan lama tidak berjalan baik dan harus didekati dengan cara baru di Rust, memang sering terjadi
  • Saya juga punya pengalaman serupa. Untuk kasus sederhana, gaya mutable dan imperatif tetap tidak masalah, tetapi semakin kompleks, saya cenderung beralih ke gaya fungsional dan menghindari perubahan sebisa mungkin. Karena borrow checker dan lifetime, pola tradisional jadi sulit sehingga secara alami saya beralih ke pendekatan fungsional. Kalau belum terbiasa mengimplementasikan secara fungsional, ini bisa terasa berat, tetapi kompiler biasanya jadi jauh lebih puas
• Async/await adalah satu-satunya alasan saya tidak memakai Rust
  • Sebenarnya saya justru menganggap async/await sebagai salah satu alasan utama untuk memakai Rust, karena itu membuat pola konkurensi jauh lebih sederhana. Pada awalnya memang terasa seperti wabah ganas yang membuat semua kode pada akhirnya harus menjadi async, tetapi setelah tahu cara berinteraksi dengan kode async, semuanya jadi lebih nyaman. Biasanya spawn, spawn_blocking, dan futures::stream mencakup 90% penggunaan, dan jika "batas" yang tepat dibuat, async juga tidak perlu menyebar ke mana-mana
  • Saya cukup paham maksudnya. Namun bagi saya, async/await di Rust justru terasa sangat pas, sehingga menjadi alasan terbesar saya memakainya. Saya juga suka sintaksnya dan tidak terlalu peduli dengan masalah function colouring. Terutama saat memakai tokio, karena tersedia versi async dari semua fungsi standar yang dibutuhkan, solusi terasa mengalir dengan baik. Hal-hal seperti ini memang bisa menjadi penghalang, tetapi menulis program konkurensi jadi jauh lebih mudah dan performanya juga bagus, jadi saya puas. Soal cancellation kadang memang sempat membuat saya bingung, tetapi saya menganggap itu lebih karena keterbatasan kemampuan saya sendiri
  • Bukankah sekarang semuanya sudah tersedia?