Rust di 2025: Menargetkan perangkat lunak fondasional

• Rust merayakan ulang tahunnya yang ke-10 tahun ini dan semakin memantapkan diri sebagai bahasa inti untuk pengembangan perangkat lunak fondasional di masa depan
• Perangkat lunak fondasional berarti lapisan yang menjadi dasar bagi segala sesuatu, seperti kernel sistem operasi, platform cloud, perangkat embedded, dan alat CLI
• Rust menurunkan hambatan dengan menyediakan performa dan keandalan setingkat C/C++ sekaligus sistem tipe yang menjamin keamanan memori
• Misi Rust tidak terbatas pada domain fondasional saja, tetapi juga memberi dampak pada pengembangan aplikasi tingkat atas melalui proyek seperti Dioxus, Tauri, Leptos
• Ke depan, Rust berencana menjadikan interoperabilitas bahasa, perluasan sistem tipe, dan penguatan ekosistem sebagai area investasi utama

---

Visi Rust: perangkat lunak fondasional

• Visi inti Rust adalah membuat perangkat lunak fondasional lebih mudah ditulis dan dipelihara
  • Perangkat lunak fondasional mencakup kernel sistem operasi, infrastruktur cloud, perangkat embedded, alat CLI, dan lain-lain yang menjadi dasar bagi seluruh sistem
  • Saat ini sudah diadopsi di berbagai tempat seperti kernel Windows dan Linux, mesin pencarian VSCode yaitu ripgrep, Deno, dan package manager Python uv
• Untuk perangkat lunak seperti ini, performa, keandalan, dan produktivitas sama-sama penting
  • Jika fondasinya runtuh, seluruh lapisan di atasnya akan terdampak, sehingga stabilitas menjadi hal yang esensial
  • Penurunan performa akan menjadi batas performa lapisan atas, sehingga overhead harus seminimal mungkin

Performa, keandalan, dan produktivitas perangkat lunak fondasional

• Perangkat lunak fondasional, seperti semua perangkat lunak lainnya, memiliki beragam kebutuhan, tetapi setiap unsurnya menjadi jauh lebih penting
  • Keandalan adalah prioritas tertinggi. Jika fondasinya gagal, semua yang berdiri di atasnya ikut gagal
  • Overhead performa menentukan batas performa lapisan atas, sehingga harus ditekan seminimal mungkin
• Sebelumnya, ada dua pilihan untuk memenuhi kebutuhan tersebut
  • C/C++ : memberikan kebebasan besar, tetapi menuntut tingkat ketelitian yang sepadan
  • Bahasa tingkat tinggi seperti Java dan Go: memerlukan pola penulisan khusus untuk menjaga performa, sehingga ada batasan dalam penggunaan abstraksi dan kenyamanan
• Rust mengubah pendekatan lama ini dengan menggabungkan abstraksi tanpa biaya (zero-cost abstraction) dan sistem tipe yang menjamin keamanan memori
• Hasilnya adalah alat yang memungkinkan penulisan kode tingkat tinggi secara aman sambil tetap mencapai performa tingkat rendah dan stabilitas memori secara bersamaan

Menurunkan hambatan masuk dan memperkuat kemampuan pengembang

• Dalam presentasi Rust, sistem tipe dan pemeriksaan statis sering diibaratkan sebagai "bayam": baik untuk Anda, tetapi tidak selalu ingin dikonsumsi
• Dalam praktiknya, sistem tipe adalah senjata yang sangat kuat bagi pengembang
• Pemula dapat mempelajari struktur perangkat lunak yang baik melalui proses mempelajari sistem tipe
• Pengembang berpengalaman dapat menemukan kesalahan dalam rancangan strukturnya sendiri dengan lebih cepat

• Pernyataan Yehuda Katz, "Abstraksi yang saya buat saat fokus membantu diri saya di masa depan saat saya lelah," juga merangkum hal ini dengan baik

Area di luar perangkat lunak fondasional

• Meski misi Rust berfokus pada perangkat lunak fondasional, itu bukan berarti area lain diabaikan
• Proyek seperti Dioxus, Tauri, Leptos memperluas penggunaan Rust ke ranah aplikasi tingkat tinggi seperti GUI dan halaman web
• Kekuatan utama Rust pada dasarnya memang berpusat pada perangkat lunak fondasional, tetapi upaya-upaya seperti ini tidak boleh diabaikan

Target ambisius dan pertumbuhan

• Karena perangkat lunak fondasional memerlukan kontrol detail tingkat rendah, aksesibilitas dan ergonomi sering kali dianggap kurang penting
• Justru karena kontrol detail tersebut diperlukan, kegunaan menjadi semakin penting
• Jika pengembang dapat dibantu agar hanya fokus pada bagian yang benar-benar penting, produktivitas bisa meningkat pesat

• Proyek-proyek yang mendorong penerapan Rust di tingkat tinggi memberi peluang untuk membuat pemrograman Rust jauh lebih nyaman
• Peningkatan ini kemudian dapat langsung tercermin juga dalam pengembangan perangkat lunak fondasional
• Intinya adalah meningkatkan kegunaan tanpa kehilangan kendali dan keandalan

Pentingnya dukungan full-stack

• Alasan lain mengapa pengembangan aplikasi tingkat tinggi di Rust terasa nyaman adalah karena seluruh stack dapat dibangun dengan satu teknologi
• Pengembang yang awalnya hanya ingin memakai Rust di sebagian area seperti layanan data plane kini semakin sering memperluasnya ke seluruh area
• Ini karena Rust memiliki produktivitas tinggi dan memungkinkan berbagi library serta kode dalam satu bahasa
• Pada dasarnya, kode yang sederhana akan tetap sederhana dalam bahasa apa pun

Pengalaman pendalaman bertahap (Iterative Deepening)

• Idealnya, pengalaman pertama pengguna Rust harus sederhana, lalu seiring perkembangan proyek, mereka dapat secara bertahap memperluas lebih banyak kontrol secara lokal
• Ini terdengar sederhana, tetapi pada praktiknya merupakan tantangan yang sangat sulit
• Banyak proyek gagal karena hambatan masuk bagi pemula terlalu tinggi, atau karena mempelajari tingkat kontrol yang lebih tinggi menuntut terlalu banyak pengetahuan
• Rust memang tidak selalu berhasil dalam hal ini, tetapi terus berupaya memperbaikinya

Rencana ke depan

• Artikel ini adalah tulisan pertama dari seri ini, dan dalam empat tulisan berikutnya akan dibahas area-area investasi yang diperlukan agar Rust menjadi lebih cocok untuk perangkat lunak fondasional
  • Interoperabilitas bahasa yang mulus (smooth language interop) dan ekstensibilitas (extensibility)
  • Kejelasan tujuan melalui sistem tipe (clarity of purpose)
  • Penguatan ekosistem: pedoman yang lebih baik, alat yang lebih baik, dan pemanfaatan Rust Foundation
  • Pada tulisan terakhir, akan dibahas pengelolaan organisasi open source Rust, termasuk cara agar kontribusi dan maintenance menjadi aktivitas yang sebisa mungkin mudah diakses dan menyenangkan

[yeorinhieut]

Meski Rust terlihat lumayan bagus, rasanya ini satu-satunya bahasa yang jadi enggan saya dekati karena fandom toksik(?)-nya.

[aer0700]

Andai saja C atau C++ punya package manager standar. Setiap melihat Cargo, saya selalu berpikir begitu.

[cosine20]

Bayam rasanya enak sekali....

[t7vonn]

Belakangan ini, nyaris tidak ada tempat yang tidak menggunakan Rust.

[lostid]

Saya bekerja di perusahaan besar, tetapi tidak ada bidang yang menggunakan Rust. Tolong jangan menggiring opini.

[t7vonn]

Jangan cari gara-gara.

[bobross0]

Duh duh duh duh duh duh duh;;

[crawler]

Jangan cari gara-gara ya, serem 😨

[shakespeares]

Waduh ;;

[qwas5544]

Duh duh duh duh duh duh;;;

[lostid]

Terlepas dari semuanya, belakangan ini gara-gara para fanatik Rust rasanya sampai muak. Di dunia offline, itu bahkan termasuk yang sangat minor di antara yang minor, tapi di online hampir seperti ISIS... ah, mending mereka ngumpul di satu tempat saja lalu main sesama mereka sendiri...

[ifmkl]

Bahkan di kalangan fanatik Rust pun, sering kali muncul keraguan apakah mereka sendiri benar-benar memakainya dengan baik.

[skageektp]

Tetap saja... kalian suka Rust, kan?
Kalian boleh benci kaum Rust, tapi tolong cintai Rust T_T

[taeunlee99]

Walau sempat kena hantam gara-gara FFmpeg, tetap saja ngomong semua kode harus ditulis dengan Rust dan semacamnya.

[GN⁺]

Komentar Hacker News

• Saat membahas software inti, bagian yang paling disayangkan dari Rust menurut komentar ini adalah ABI. Jika ingin membuat OS dengan Rust dan menyediakan layanan yang kaya, aplikasi seharusnya tetap bisa digunakan tanpa perlu mengompilasi ulang library meskipun OS di-upgrade. Windows menyelesaikan masalah ini dengan COM, Apple dulu dengan dynamic dispatch milik ObjC (dan sekarang dengan Swift ABI), Android dengan JVM dan bytecode. Rust pada praktiknya hampir hanya mendukung extern "C", sehingga pemanfaatan dynamic library menjadi terbatas. Menyediakan ABI tanpa lapisan VM (JVM, .NET) sangatlah sulit, dan karena detail implementasi yang sudah ditetapkan tidak boleh diubah lagi, wajar jika prioritasnya rendah. Dalam praktiknya, model seperti ini yang benar-benar berhasil hanya Swift dan COM. Jika Rust mengadopsi ABI yang lengkap, bahasa ini akan mendekati bahasa yang hampir sempurna. (Jika dependensi dikelola dalam bentuk biner, waktu kompilasi juga akan jauh berkurang)

  • Dijelaskan bahwa alasan Rust pada dasarnya hanya ingin mengadopsi stabilitas ABI yang bersifat opt-in adalah karena ia mengejar zero-cost abstraction. ABI yang stabil disertai penurunan performa, dan hal ini dibuktikan melalui kasus C++ (penjelasan terkait ABI C++). Untuk memuat plugin Rust secara dinamis (dlopen) antar-Rust, ada alat seperti stabby dan abi_stable, dan keduanya bekerja cukup baik. Untuk interoperabilitas antarbahasa yang lebih umum, crABI (proposal crABI) bisa menjadi alternatif masa depan. Namun ini bukan masalah yang bisa diselesaikan Rust sendirian; dukungan dan kerja sama dari berbagai komunitas lain seperti bahasa lain dan distribusi Linux juga dibutuhkan. Disebutkan juga bahwa karena Rust adalah bahasa yang secara eksplisit memilih cara I/O dan alokasi memori, arsitektur seperti Swift yang menyelesaikan semuanya hanya dengan shared library mungkin tidak cocok sepenuhnya.
  • Upaya untuk menyelesaikan masalah yang hampir sama juga sedang dilakukan lewat Wasm Components. Jika WebAssembly adalah format instruksi yang portabel, maka WebAssembly Components adalah format eksekusi/linking yang portabel. Memang tidak semudah repr(wasm)/extern "wasm", tetapi dengan memanfaatkan wit-bindgen atau target wasm32-wasip2, ini bisa digunakan tanpa terlalu sulit. Video pengantar Wasm Components
  • Ada yang menyatakan ragu apakah ini benar-benar diperlukan. Memang akan lebih nyaman jika lebih banyak macam "hal" (slices, trait objects, dan sebagainya) bisa diteruskan sebagai antarmuka, tetapi secara realistis semua yang dibutuhkan sudah bisa dilakukan hanya dengan ABI extern "C". Selain itu, dia juga pernah melihat proposal untuk memperluas ABI extern ke lebih banyak tipe
  • Ada yang pernah melihat presentasi di konferensi Rust tentang topik ini yang sangat merujuk pada pendekatan Swift. Ia memperkirakan arah perkembangannya nanti mungkin ke sana
  • Sebenarnya hal seperti itu sudah ada. Namanya adalah 'C'

• Sangat menyukai Rust, tetapi berharap beberapa masalah kronis yang menjengkelkan juga mendapat lebih banyak perhatian

  • 1. Ada masalah self-referencing struct. Misalnya, ingin menyimpan source file dan AST hasil parsing dalam struct yang sama, tetapi saat ini itu tidak mudah. Akan bagus jika ada sesuatu seperti offset reference
  • 2. orphan rule (aturan trait yatim). Alasannya bisa dipahami, tetapi tetap saja aturan ini merepotkan. Bisa diatasi dengan fitur baru (kadang perlu pembungkus 2–3 lapis!), tetapi masih dipertanyakan apakah memang harus begini
  • 3. Untuk mendapatkan waktu kompilasi yang layak, proyek harus dipecah menjadi banyak crate kecil. Alasannya bisa dipahami, tetapi hasil akhirnya kurang baik. Sebuah crate diperlakukan sebagai satu unit kompilasi, dan ini karena dependensi siklik diizinkan. Namun kebanyakan kode sebenarnya tidak memiliki dependensi siklik, jadi akan bagus jika ini dibuat opt-in, atau item/file di dalam crate otomatis dipecah menjadi unit kompilasi berdasarkan graf dependensi
  • Ini hanya yang terpikir saat itu, tetapi rasanya masih ada lebih banyak lagi. Meski begitu, Rust tetap bahasa terbaik dalam hidupnya, walaupun kritik ini bersifat konstruktif
    • Ditunjukkan bahwa Rust tidak mengizinkan dependensi siklik antar-crate, tetapi mengizinkan dependensi siklik antar-modul di dalam crate. Meskipun dianggap sebagian besar kode tidak memiliki dependensi siklik, misalnya modul apa pun yang punya submodul test tetap terkena dependensi siklik. Untuk benar-benar memisahkan test, semua fungsi test harus didefinisikan di crate root, yang dalam praktiknya tidak efisien
    • Sangat setuju dengan poin 1 dan 2. Ditambahkan juga poin 4, yaitu berharap ada partial self borrows (fitur agar metode hanya meminjam sebagian dari struct). Untuk poin 3, menurutnya dukungan yang lebih baik seperti bisa merilis banyak crate sekaligus perlu ada lebih dulu
    • Terkait orphan rule, ia meminta penjelasan lebih lanjut apakah yang dimaksud adalah Rust perlu memperkenalkan alternatif yang lebih baik, atau hanya perlu fitur yang bisa menggantikan aturan ini
    • Sangat setuju soal orphan rule. Akan bagus jika di application crate aturan ini bisa dinonaktifkan, atau setidaknya dilonggarkan ketika higienitas yang memadai bisa dijamin, misalnya lewat proc macro

• Sambil merenungkan ungkapan “Smooth, iterative deepening”, ada yang berpikir bahwa Rust terlalu menekankan kompatibilitas lintas bahasa sehingga justru berisiko menambah kompleksitas dan mengurangi keamanan. Dalam kasus seperti ini, akan lebih membantu jika yang diganti adalah bagian dasar sistem seperti libc. Go hampir tidak melakukan pemanggilan lintas bahasa. Google membangun sendiri library inti untuk memperkuat fondasinya, tetapi di Rust ada banyak versi library dasar yang tersebar dan banyak yang belum matang

  • Dijelaskan bahwa selama 20 tahun terakhir, salah satu tugas inti ilmu komputer adalah membuat banyak program di mesin yang sama bisa berkomunikasi secara efisien. Kebanyakan upaya mencoba mengakali fondasi DLL milik Microsoft dengan source dan state, atau object request broker seperti CORBA yang gagal mapan. RPC ala qnx juga sama. Akibatnya, hingga sekarang kita terus mengulangi upaya memaksa hal-hal yang sebenarnya tidak cocok untuk disatukan
  • Sebenarnya semuanya bisa saja ditangani lewat socket, tetapi socket adalah stream byte mentah, jadi merupakan abstraksi yang keliru; hanya saja tetap dipakai karena mudah digunakan
    • Menurut saya, yang dibahas dalam postingan ini bukan benar-benar soal menggantikan shared library lintas bahasa seperti DLL/COM/Wasm components, melainkan kebutuhan praktis untuk memigrasikan C++ ke Rust secara bertahap. Untuk meningkatkan keamanan memori secara keseluruhan, pertanyaan besar adalah 'bagaimana dengan program yang sudah ada', dan saat ini tingkat interoperabilitas Rust dan C++ masih kurang. Jika kedua bahasa bisa bekerja sama mulus di level source, kemungkinan nyata bahwa Rust akan menggantikan sebagian besar wilayah C++ juga akan meningkat
    • Kadang rasanya kalau socket dan protokolnya cocok, itu hampir menjadi abstraksi lintas bahasa yang terbaik. Kalau begitu, saya jadi penasaran abstraksi pemanggilan lintas bahasa seperti apa yang dianggap benar-benar ideal

• Ditekankan bahwa "menghindari alokasi, mencegah GC terpicu" tidak sesuai dengan konsep GC dan JIT modern. GC modern dalam banyak kasus hampir tidak punya stop-the-world latency, dan penggunaan CPU total untuk GC terutama ditentukan oleh rasio antara resident set dan ukuran heap. JIT punya lebih banyak peluang optimisasi dibanding AOT, dan bisa mengeksplorasinya dengan lebih agresif (berkat speculative optimization). Yang benar-benar penting dalam praktik adalah latensi startup/warm-up dan overhead memori, serta bukan performa worst-case yang memburuk melainkan performa rata-rata. Selain itu, manajemen memori manual juga belum tentu lebih efisien, dan bahkan jika penggunaan RAM nyata naik 3x, perbedaan biayanya bisa nol. Direkomendasikan juga presentasi konferensi ISMM yang membahas topik ini dengan baik

  • Ada yang ingin tahu lebih konkret apa yang dimaksud dengan pendapat bahwa JIT melihat lebih banyak peluang optimisasi. JIT pada akhirnya hanyalah pelengkap AOT
  • Ada pertanyaan implementasi apa yang dimaksud dengan 'GC modern' di sini

• Ada yang menilai komentar dan diskusi yang ditandai justru menangkap inti persoalan dengan baik. Pertanyaan seperti "mari buat standar bahasa dengan spesifikasi resmi" dan "kita butuh beberapa implementasi" adalah pertanyaan yang penting secara realistis. Khususnya, @infogulch dengan tepat menyoroti bahwa agar bahasa bisa menjadi fondasi industri, spesifikasi resmi itu perlu (komentar rujukan)

  • Dijelaskan dengan jenaka bahwa alasan penandaan komentar itu tidak jelas, dan dalam kenyataannya banyak bahasa yang menjadi fondasi industri meskipun tidak punya spesifikasi standar atau tidak memiliki banyak implementasi. Misalnya Ruby memang punya standar ISO lama, tetapi itu hanya untuk versi tersebut, sementara Python pada dasarnya menjadikan implementasinya sendiri sebagai standar. Rust juga demikian, dan dari sudut pandang pengguna arus utama, mereka tidak akan berpikir harus mengganti bahasa hanya karena hal-hal seperti ini
  • Karena penasaran dengan "standar bahasa resmi", ada yang mencari dan menemukan dokumen referensi di rust-lang/reference. Proyek Rust cukup serius dalam menspesifikasikan bahasa. Dalam tulisan blog visi spesifikasi terbaru, kemajuan dijelaskan secara rinci. Pekerjaan spesifikasi ini sangat besar dan sulit, tetapi tetap berjalan aktif sampai-sampai PR masih di-merge ke branch master bahkan saat akhir pekan
  • Semoga bagian tentang perlunya banyak implementasi juga terbantu oleh fakta bahwa kompilator Rust alternatif seperti gccrs sudah sedang dikembangkan secara resmi
  • Ada sudut pandang skeptis bahwa LLM dan Rust pada dasarnya sama-sama hanya memuaskan sebagian orang dan sedikit meningkatkan produktivitas. Namun ia tidak setuju dengan sikap komunitas yang berusaha memperbesar pengaruh secara tidak bertanggung jawab
  • Ada yang meminta penjelasan lebih lanjut tentang apa tepatnya yang dimaksud dengan published language standard, dan manfaat konkretnya di dunia nyata
  • Tidak ada keluhan terhadap Rust itu sendiri, tetapi ada kekecewaan terhadap sikap sebagian pengguna yang tidak memahami betapa pentingnya spesifikasi formal. Semua sistem komputasional pada akhirnya ditentukan umur dan keandalannya oleh seberapa formal pendekatan terhadap spesifikasinya. Tanpa spesifikasi yang jelas, kita sepenuhnya bergantung pada fakta bahwa 'suatu implementasi kebetulan bekerja untuk input tertentu', sehingga berbahaya membangun sistem di atas dasar yang rapuh seperti itu. Dalam komputasi, spesifikasi itulah sistemnya (implementasi hanya optimisasi tambahan)

• Orang sering mempertanyakan apakah Rust memang perlu punya spesifikasi, dan hal ini justru dianggap menunjukkan bahwa engineering nyata masih terlalu sedikit dalam software engineering

  • Ada yang berpikir software engineering bukan engineering sungguhan. Tidak seperti jembatan atau gedung tinggi yang tidak bisa dibangun tiga kali untuk memperbaikinya, di software justru pendekatan itu sering bagus

• Menanggapi komentar yang menyebut Rust sebagai "bahasa yang hanya dipakai orang yang ingin terlihat seperti programmer", ada yang mengatakan bahwa dirinya memang orang yang mencintai pemrograman, dan Rust terasa seperti kejutan yang menyegarkan. Ia sama sekali tidak ingin kembali ke masa lalu ketika C++ terasa sangat menyiksa. Selain itu, ia tidak menganggap standar bahasa (donasi spesifikasi Ferrocene) atau jumlah implementasi sebagai hal yang penting. Python dan Java juga berjalan baik dengan bergantung pada satu implementasi utama. C++ justru menjadi makin rumit di tiap platform karena harus mendukung banyak kompilator. Ia juga tidak tahu persis apa yang dimaksud dengan "kekacauan" cargo, dan menurutnya sisi C++ jauh lebih tidak nyaman

  • Ada yang bertanya masalah spesifik apa yang dimaksud terkait cargo
  • Ditambahkan juga keraguan apakah keberagaman standar/implementasi bahasa dan tool benar-benar sepenting itu, apakah tidak terlalu dini, dan apakah Rust akan sesukses sekarang jika sejak awal menghabiskan energi untuk hal-hal itu. Artikel terkait tampaknya bukan sedang mendorong penggantian total yang menyeluruh, melainkan menekankan dukungan/kecocokan untuk target penggunaan tertentu
  • Cargo saat ini dianggap package manager terbaik di antara bahasa-bahasa besar di dunia. Ia belajar dengan baik dari kegagalan package manager sebelumnya, sangat rapi, dan level infrastrukturnya tinggi. Memang mungkin masih perlu sedikit perbaikan seperti namespace dan repeatable build yang sepenuhnya lengkap, tetapi memasang cargo saat ini ke bahasa lain hampir mustahil. Sangat sedikit bahasa yang punya infrastruktur sebagus ini