Inti dari Rust

• Rust adalah bahasa dengan berbagai konsep yang saling terkait erat, sehingga untuk memahami program dasar sekalipun, banyak elemen harus dipelajari secara bersamaan
• Fungsi, generik, enum, pattern matching, trait, referensi, ownership, Send/Sync, Iterator, dan lainnya semuanya merupakan elemen inti yang dirancang untuk saling berinteraksi
• Dibandingkan dengan JavaScript, di JS kita masih bisa menulis kode hanya dengan memahami beberapa konsep, tetapi di Rust kita baru bisa menulis kode yang bermakna setelah memahami konteks bahasa secara keseluruhan
• Kompleksitas Rust seperti ini memang meningkatkan hambatan belajar, tetapi sekaligus memberikan keamanan dan konsistensi, serta sangat memengaruhi cara perancangan kode
• Kerapian struktur bahasa seperti ini membuat Rust istimewa, dan visi tentang “Rust yang lebih kecil” mengajak kita kembali melihat filosofi bahasa yang dipadukan secara presisi

---

Sulitnya mempelajari Rust

• Meski Rust memiliki hambatan masuk yang tinggi, banyak orang telah berkontribusi pada dokumentasi, API, dan peningkatan diagnostik
• Konsep dasarnya mencakup fungsi sebagai first-class object, enum, pattern matching, generik, trait, referensi, borrow checker, keamanan konkurensi, dan iterator
• Konsep-konsep ini saling bergantung dan saling terkait, sehingga sulit dipelajari satu per satu secara terpisah, dan sebagian besar pustaka standar juga memanfaatkan fitur-fitur ini
• Untuk memahami bahkan hanya sekitar 20 baris kode Rust, kita perlu menangkap banyak elemen sekaligus seperti paradigma fungsional, Result dan penanganan error, tipe generik, enum, iterator, dan lainnya

Perbandingan Rust dan JavaScript

• Saat program pendeteksi perubahan file yang sama ditulis dalam Rust dan JS, Rust memperlihatkan banyak konsep bahasa yang saling terjalin
• Di JS, pada dasarnya cukup memahami fungsi dan penanganan null untuk menulis kode yang bisa berjalan
• Ini bukan berarti Rust sekadar lebih sulit, melainkan menunjukkan bahwa Rust adalah desain yang menuntut pemahaman struktural atas keseluruhan bahasa

Desain Rust yang saling terhubung

• Inti Rust adalah gabungan fitur-fitur yang dirancang secara organik
  • Enum terasa tidak praktis tanpa pattern matching, dan pattern matching juga terbatas tanpa enum
  • Result dan Iterator tidak mungkin diimplementasikan tanpa generik
  • Konsep Send/Sync dan batasan println hanya bisa diekspresikan dengan aman jika ada trait
  • Borrow checker menjamin keamanan Send/Sync melalui analisis capture pada closure
• Keterkaitan seperti ini membuat Rust bukan sekadar kumpulan fitur, melainkan sebuah sistem bahasa yang terintegrasi

Visi Rust yang lebih kecil

• Pada 2019, without.boats menyebut “Smaller Rust” saat membahas kemungkinan Rust yang lebih kecil dan lebih halus
• Kini Rust sudah jauh lebih besar, tetapi gagasan tentang Rust yang lebih kecil mengingatkan kita pada hakikat desain bahasa yang saling bertaut secara presisi
• Daya tarik Rust terletak pada fakta bahwa elemen-elemennya, saat berdiri sendiri maupun saat digabungkan, memberikan daya ekspresi dan keamanan yang kuat

Kesimpulan

• Rust memang sulit dipelajari, tetapi konsistensi dan integrasi dari konsep-konsep yang saling terkait menjadi kekuatan besarnya
• Berkat struktur ini, Rust membuat pengembang bukan sekadar menulis kode, tetapi juga membangun cara berpikir yang mempertimbangkan keamanan dan performa sekaligus
• Hakikat Rust ada pada “bahasa inti yang kecil dan dirancang dengan presisi”, dan ini tetap menjadi filosofi penting bahkan pada Rust yang telah berkembang saat ini

[GN⁺]

Opini Hacker News

• Ada ironi bahwa bahkan program JS yang "sederhana" pun mengandung bug. Dokumentasi fs.watch secara eksplisit menyebutkan bahwa filename di callback bisa bernilai null dan wajib diperiksa. Di Rust, fakta ini akan tercermin di sistem tipe sehingga pasti dipaksa untuk ditangani, tetapi di JS orang mudah menulis kode secara serampangan. Dokumentasi terkait
  • Jika memakai Typescript, pemeriksaan null akan dipaksakan. Jadi ini menurut saya contoh yang bagus bahwa TS adalah langkah yang relatif ringan di JS untuk lebih mendekati correctness ala Rust
  • Ada bug tambahan juga: for path in paths seharusnya for (const path of paths). Memang JS akan langsung error kalau tanpa tanda kurung, tetapi perbedaan in dan of adalah bahwa in mengiterasi indeks iterable, bukan nilainya, sehingga indeks itu akhirnya dikonversi menjadi string dan masuk sebagai argumen pertama fs.watch. Bahkan TypeScript pun mungkin tidak menangkap kesalahan ini
  • Seperti yang sudah ditunjukkan, sintaks loop-nya sendiri memang tidak tepat, dan cukup dijalankan sekali saja untuk langsung tahu. Jadi lebih masuk akal menganggap penulis tidak terlalu hati-hati menulis kode JS itu, dan hal tersebut tidak terlalu berarti terhadap poin utamanya
  • Mungkin saya terlewat, tetapi saya penasaran kind itu datang dari mana. Di console.log("${kind} ${filename}"), seharusnya eventType yang berupa string, bukan kind
• Saya ingin memberi satu koreksi kecil. println di Rust hanya bisa mencetak tipe yang mengimplementasikan trait Display atau Debug. Jadi Path tidak bisa dicetak secara langsung. Tidak semua OS menyimpan path yang sesuai UTF-8, sedangkan semua tipe string Rust berbasis UTF-8. Artinya, menampilkan Path bisa menimbulkan kehilangan informasi. Path mengembalikan tipe yang mengimplementasikan Display melalui metode display. Rust memasukkan ini ke sistem tipe, tetapi di JS/TS sulit mengekspresikan bahwa string internalnya UTF-16, dan path non-Unicode harus ditangani langsung dengan TextEncoder/TextDecoder agar benar. Dari pengalaman saya dulu, ketika server mengirim teks dalam Shift_JIS lalu dibaca dengan response.text(), runtime hanya menghasilkan string kosong. Jika tidak terbiasa dengan isu encoding, Anda bisa menghabiskan berhari-hari untuk debugging situasi seperti ini. Selain itu, contoh JS tersebut punya bug dan kesalahan sintaks yang tidak ada di kode Rust (di loop harus for-of, bukan for-in). Saya juga tidak merasa contoh ini sekadar memakai "fungsi kelas satu"; Anda tetap perlu memahami iterator seperti di Rust, dan ia memakai CommonJS. Selain itu ada async/await, Promises, dan top-level await yang juga harus dipelajari, dan top-level await sendiri baru belakangan didukung di sebagian runtime termasuk node. Masih ada engine JS tertentu (misalnya Hermes milik React Native) yang belum mendukungnya

  • Itulah alasan saya terus memakai Rust. Contoh ini hanya satu kasus, tetapi masalah-masalah kecil dan jebakan seperti ini selalu tersebar di bahasa lain. Mungkin tiap masalah tidak selalu muncul sendiri-sendiri, tetapi jika dikumpulkan sepanjang siklus hidup program, bug aneh akan terus muncul entah dari mana dan harus terus dicari. Di Rust hal seperti ini tidak terjadi. Sistem tipenya memblokir sangat banyak kasus absurd sejak awal. Dalam praktiknya, setelah saya merilis software yang fiturnya sudah lengkap dengan Rust, saya hanya sesekali menambah fitur, dan pekerjaan debugging bug umum nyaris hilang. Tentu bug logika tetap bisa terjadi di mana saja, tetapi Rust menutup sumber masalah dari ketidakcocokan tipe/struktur yang konyol seperti di bahasa lain, sehingga produktivitas dan maintainability terasa sangat berbeda

  • Secara pribadi saya merasa banyak developer JS/TS yang tidak benar-benar paham thenable/Promise dan async-await. Saya juga pernah melihat ini:

    var fn = async (param) => new Promise((res, rej) => {
      fooLibraryCall(param).then(res).catch(rej);
    });
    

    Wrapper berbentuk callback dibungkus lagi sebagai Promise lalu dipakai kembali di dalam fungsi async. Setiap kali melihat ini rasanya pedih sekali. Dan saya benar-benar melihat kode seperti ini di banyak tempat. Belum lagi kalau memikirkan import modul dan async import(), transpile, code splitting, dan seterusnya, semuanya benar-benar kompleks

• Kutipan Bjarne itu menurut saya sebenarnya hanyalah sales pitch untuk terus membenarkan bahwa C++ makin memburuk. Mungkin di awal tulus, tetapi sekarang polanya berulang. Menurut saya strukturnya seperti ini:
  1. "Di dalam C++ ada bahasa yang lebih kecil dan lebih bersih"
  2. Tetapi karena bahasanya tidak bisa diekstrak sebagai subset, maka dibuat dulu superset (ditambah banyak fitur), lalu subset-nya dibahas belakangan
  3. Superset itu masuk ke C++N+1 yang baru. Pembahasan subset yang sesungguhnya ditunda lagi sambil diulang
  4. C++N+1 jadi makin kompleks, dan siklus ini berulang selamanya Saya tidak mengerti kenapa orang yang sudah berkali-kali melihat pola ini masih bertahan. Pada akhirnya, "bahasa yang lebih kecil dan lebih bersih" itu tidak pernah benar-benar muncul. Selalu kembali ke langkah pertama
  • Ini mengingatkan saya pada xkcd 927 xkcd 927. Standar C++ makin lama makin rumit; memang ada perubahan bagus, tetapi sering juga tidak selaras dengan versi sebelumnya, dan source code makin berantakan. Saya mengelola dua library OSS, tetapi sekarang hampir tidak pernah memakainya. Belakangan saya sering berpikir sampai kapan saya harus terus bertahan. Beralih ke Rust setelah C++11/14/17/20 terasa benar-benar menyegarkan. Meski begitu, Rust juga cukup besar jika ingin memahami semuanya. Poin yang disampaikan tulisan ini terasa sangat tepat
• Apakah tidak ada yang langsung terdistraksi saat melihat shebang (rustscript yang bisa dieksekusi langsung)? Saya kaget seperti saat dulu menemukan hal yang sama di Go. Terlihat cukup berguna dan tampaknya memadai untuk kebutuhan dasar. Saya juga pernah melihat hal serupa di proyek yang mengelola pipeline build/test dengan rust. Untuk penggunaan seperti itu, ini bisa menjadi alternatif yang cukup bagus. Namun secara umum, kalau saya butuh skrip yang sedikit melampaui bash, saya memakai Deno+TS. Saya paling lama bekerja dengan JS (28 tahun), lalu C# selama 24 tahun. Saya memakai Node sejak masa-masa awal. Dari sisi berbagi paket/sentralisasi, Deno lebih mudah dikelola dibanding Node atau Python. Frontmatter cargo juga bekerja dengan cara yang mirip
  • Saya orang yang merancang/mengimplementasikan integrasi script ke cargo secara langsung (meski selama ini juga ada banyak implementasi pihak ketiga). Saya sangat senang melihat kasus penggunaan nyata dan senang fitur ini disebutkan. Lihat juga dokumentasi. Ada diskusi panjang soal bentuk yang tepat, bagaimana mengaitkannya dengan bahasa, dan seberapa luas cakupan rilis pertamanya. Saat ini kami sedang merapikan style guide dan pembaruan Rust reference, dan pekerjaan besar yang tersisa adalah detail terkait rustfmt, rust-analyzer, perbaikan bug di rustc, serta peningkatan pelaporan error di Cargo. Saya sendiri setiap hari menulis skrip reproduksi issue dengan cargo script
  • Saya memang mulai menelusuri kata kunci fitur -Zscript lalu terdistraksi saat riset. Ini sudah berjalan sejak 2023, dan ada issue terbuka yang tampak hampir selesai. Saya juga melihat di repositori ZomboDB bahwa mereka menangani pipeline build dengan rust, meski saya tidak sepenuhnya memahami konteks keseluruhannya. Saya juga ingin menekankan betapa bergunanya frontmatter cargo untuk portabilitas skrip. Cukup berbagi satu file saja, lalu dependensi bisa langsung diambil dan dipakai tanpa instalasi/inisialisasi tambahan seperti pada Python atau Node.js
  • Ada yang bilang hal yang sama bisa dilakukan di Go, tetapi saya penasaran apakah bisa dijelaskan lebih rinci. Kalau maksudnya tautan ini, saya juga tertarik
  • Walaupun saya lama memakai JS dan C#, saya rasa memilih suatu sistem pada 2025 dengan alasan seperti itu kurang masuk akal. Selama 20 tahun terakhir, sangat banyak hal yang sudah jauh membaik
  • Itu cuma fitur dasar Unix. File yang diawali dengan #!/some/path tinggal dijalankan oleh shell dengan menyerahkan seluruh file ke perintah yang ditentukan lewat stdin
• Saat membaca ungkapan bahwa di dalam Rust "sedang muncul bahasa yang lebih kecil dan lebih bersih", saya penasaran sebenarnya bahasa yang dimaksud itu apa. Dari tulisannya, tampaknya referensi, lifetime, trait, enum, dan lain-lain tetap harus ada agar semuanya berjalan, jadi rasanya nyaris tidak berbeda dari Rust. Di bagian akhir muncul dua petunjuk, yaitu "Rust yang ingin saya pakai" dan "Rust masa lalu", tetapi itu terasa kurang jelas. Saya juga membaca "Notes on a smaller Rust" oleh withoutboats, tetapi karena tujuan desainnya sendiri berbeda dari Rust, itu lebih seperti menunjukkan pelajaran yang bisa dipetik dari Rust saat merancang bahasa baru, bukan bahasa yang sedang berusaha menjadi Rust. Itu bukan bahasa yang ingin menjadi Rust, melainkan contoh bahasa yang disesuaikan dengan tuntutan "mainstream" (misalnya GC, penyederhanaan kompilasi/sintaks, dan sebagainya). Kedua, ada juga pernyataan "bahasa yang saya cintai saat pertama kali belajar pada 2018 adalah 'Rust yang lebih kecil' itu", tetapi sebenarnya sejak 2018 Rust tidak berubah banyak secara esensial. Perubahan seperti edition kebanyakan adalah peningkatan fleksibilitas sintaks, dan pengecualian besar yang nyata hanya async dan const. Kalau begitu, mestinya bisa langsung dikatakan bahwa "Rust sebelum async dan const masuk itu lebih kecil dan lebih bersih", tetapi tulisan aslinya tidak menjelaskannya secara seterang itu, yang menurut saya agak disayangkan
  • Jika bicara tentang 'Rust yang lebih kecil dan lebih bersih', contoh yang terlintas bagi saya adalah bahasa Austral
  • Ada juga yang berpendapat bahwa bahasa yang lebih sederhana (lebih kecil) masih mungkin dibuat sambil tetap mempertahankan konsep inti Rust. Misalnya dengan menghapus Copy trait, reborrowing, deref coercion, into_iter otomatis di loop, pemanggilan drop otomatis saat scope berakhir (ini pun bisa dipanggil langsung atau dijadikan error oleh compiler), default :Sized di trait bound, lifetime elision, match ergonomic, dan berbagai otomatisasi/kemudahan lain, kita bisa memperoleh Rust yang benar-benar lebih sederhana secara mekanis. Tetapi bahasa seperti itu akan sangat tidak nyaman dipakai sehari-hari. Ironisnya, elemen-elemen tadi justru dirancang untuk pemula
  • Saya membacanya dengan sangat saksama. Memang maksud saya sebenarnya adalah bahwa Rust sebelum pengenalan async dan const itu lebih kecil dan lebih bersih. Alasan saya tidak mengatakannya secara terlalu gamblang adalah karena saya punya banyak teman yang mengembangkan fitur-fitur tersebut. Matklad mengungkapkannya dengan sangat baik di lobste.rs. Rust 2015 lebih terasa selesai dan lebih konsisten, tetapi visi Rust bukanlah koherensi sempurna, melainkan menjadi bahasa yang berguna di industri
• Saya mungkin bias, tetapi saya menganggap Rust adalah bahasa yang paling mendekati sempurna. Borrow checker memang menyebalkan, tetapi itu memang perlu. Jika kode yang sama-sama buggy ini ditulis dalam C, yang terjadi mungkin keruntuhan di runtime—dan pada akhirnya bug itu tetap harus diperbaiki juga. Bedanya, Rust memaksa Anda menyelesaikan bug itu sebelum kompilasi, sedangkan di C Anda harus panik menangani error di tengah malam. Bukan berarti Rust itu sulit; ia hanya menuntut perubahan cara berpikir. Diperlukan pergeseran paradigma ke arah penulisan kode yang aman dan secure. Kebanyakan perubahan memang terasa tidak nyaman, dan saya rasa itulah akar penolakan orang terhadap Rust
  • Rust jauh dari kata sempurna
    • Saya rasa compiler terlalu bebas menentukan kapan dan dalam urutan apa deref diterapkan. .into() dan trait From menangani konversi tipe dengan cara yang terlalu tersembunyi. Bahkan di standard library pun ada banyak fungsi "kenyamanan" semacam ini. Akibatnya tipe objek jadi ambigu, dan sulit melacak hubungan antara pemanggilan fungsi dan implementasinya (meski IDE memang sedikit membantu)
    • Implicit return menyamarkan alur program dan mengundang kesalahan. Operator tanda tanya juga tidak terlalu saya sukai
    • Rust terlalu memecah modul kecil-kecil, sehingga untuk melakukan sesuatu yang berguna Anda bisa butuh ratusan dependency. Masing-masing harus dikelola dan di-vendor sendiri agar build tetap stabil, dan itu sangat merepotkan
    • Async Rust saat ini benar-benar kacau
  • Keluhan utamanya bukan pada borrow checker itu sendiri, melainkan bahwa "gumpalan" Rust sudah menjadi terlalu besar. Bagi orang-orang yang menyukai Rust 2018 yang lebih kasar(?) dan belum lengkap (termasuk saya), Rust sekarang terasa kurang menarik. Tentu kalau sudah mahir, kekuatannya luar biasa, tetapi kadang saya bertanya apakah usaha sebesar itu benar-benar sepadan. Pada 2025, untuk alternatif C/C++ saya mungkin akan memilih Zig (satu-satunya pengecualian adalah pekerjaan Postgres; ekosistem pgrx benar-benar luar biasa). Tetap saja, apa pun masih lebih baik daripada bekerja dengan C
• Saya rasa Rust tidak seharusnya direkomendasikan sebagai bahasa pertama. Belajar bahasa pertama memang sudah sulit, dan di Rust Anda bahkan sulit melihat kode berjalan sampai semuanya benar-benar sempurna karena error compiler. Itu sangat membuat frustrasi dan orang mudah menyerah. Saya akan menyarankan mulai dari Python, JavaScript, atau Lua, lalu cepat membuat sesuatu seperti game dan belajar lewat iterasi
  • Pengalaman saya berbeda. Di perusahaan kami ada engineer ML yang hanya tahu Python, lalu ingin berkontribusi ke codebase Rust. Saya jelaskan dasar-dasarnya sekitar satu jam, dan dia cepat beradaptasi serta produktivitasnya langsung naik. Faktanya, saat membuat game lalu program crash karena string diberikan ke fungsi numerik, melacak penyebabnya bisa menghabiskan banyak waktu. Di Rust, compiler langsung menandai bahwa "ini string, seharusnya int", jadi debugging malah bisa lebih cepat selesai. Daripada seharian memperbaiki error kompilasi, lebih baik begitu daripada seminggu tersiksa oleh error runtime
  • Saya adalah orang yang dikutip di bagian paling atas blog itu. Saya sudah mengajar Rust sebagai bahasa pertama kepada lebih dari 400 orang, dan karena itu saya merasa klaim-klaim di thread ini sangat menarik. Melalui pengalaman langsung yang panjang, saya sudah mengumpulkan banyak bukti bahwa ini bukan cuma mungkin, tetapi cukup berhasil
  • Saya sendiri masih belum yakin. Saya ingin melihat pengajar yang bagus mencoba Rust sebagai bahasa pertama. Kini generasi sudah berganti dan kampus banyak memakai Python, tetapi secara teoretis saya bisa membayangkan Rust sebagai bahasa pertama meningkatkan level seluruh kohor (meski tingkat gagal bisa terlalu tinggi hingga menimbulkan masalah administratif, atau sebaliknya mahasiswa unggul justru bisa belajar lebih banyak). Hal-hal seperti move assignment atau makna keyword const, yang dipelajari di Rust, mungkin justru mengurangi beban untuk menghapus kebiasaan keliru yang dipelajari dari bahasa-bahasa lama di kemudian hari
  • Biasanya saya akan menyarankan menghindari static typing sebagai bahasa pertama. Saya sendiri menyukai static typing, tetapi dari sudut pandang pemula itu hanya menambah kebingungan. Error compiler sering bersifat kontrafaktual, dan pesan seperti "compiler tidak bisa membuktikan bahwa ini bukan none" terasa jauh lebih sulit daripada runtime crash pada test case yang langsung menunjukkan lokasinya. Dengan mencetak nilai baris demi baris, kebanyakan masalah biasanya cepat terpecahkan, tetapi ketika terhalang error compiler yang rumit, orang bisa benar-benar tersesat lama
  • Rust bukan bahasa yang buruk jika Anda bisa menerima semuanya sekaligus. Masalahnya, tidak ada orang yang belajar bahasa dengan cara seperti itu, dan tanpa pemahaman yang cukup tentang konsep-konsep utamanya, orang akan terus tersandung di Rust. Dan pada akhirnya banyak juga konsep di sana yang sama sekali tidak dipelajari di bahasa lain, sehingga saat pindah ke bahasa baru, rasa frustrasi itu bisa terulang
• Contoh paling dekat dari "Rust sederhana" yang pernah saya lihat adalah Gleam. Kelihatannya cukup terinspirasi dari Rust
  • Anggapan bahwa Gleam terinspirasi dari Rust itu keliru. Pembuatnya tidak pernah menyatakan demikian secara resmi. Compiler-nya memang ditulis dengan rust, tetapi paradigma dan runtime target Gleam sama sekali berbeda, jadi itu bukan pengganti Rust
  • Kalau menginginkan gaya 'simple rust' lain, saya juga menyarankan melihat fsharp
  • Halaman utama Gleam memuat pesan tentang hak kulit hitam, hak trans, dan anti-Nazi, jadi saya sama sekali tidak tertarik pada bahasa ini
  • Saya penasaran apakah di Gleam bisa membuat 3D
• Saya terganggu oleh fakta bahwa "program Rust itu tidak dijelaskan melakukan apa". Ada penjelasan teknis yang sangat banyak, tetapi tidak ada ringkasan tentang program itu sebenarnya melakukan apa. Padahal kenyataannya hanya memantau perubahan file lalu mencetaknya. Fakta bahwa tugas sesederhana ini pun implementasinya jadi kompleks di Rust menunjukkan dengan baik sulitnya bahasa ini, karena Anda harus memperhatikan detail internal yang tidak berhubungan dengan masalah sebenarnya. Saya melihat kompleksitas ini sekaligus sebagai tantangan yang akan dihadapi dan juga sebagai penghalang yang diciptakan sendiri
  • Bahasa lain juga punya masalah yang sama, tetapi Rust membantu Anda menanganinya lebih awal. Tidak semua nama file bisa dicetak, dan kebanyakan bahasa hanya melemparkan masalah itu ke pengguna. Rust dengan jelas menandai error/kegagalan lewat tipe kembalian, sedangkan bahasa lain memerlukan mekanisme lain seperti exception handling. Sepintas tampak sederhana, tetapi sebenarnya pendekatan Rust mungkin justru lebih intuitif
  • Implementasinya sendiri sebenarnya sangat sederhana untuk ukuran bahasa berperforma tinggi. Semuanya muat dalam satu halaman. Bukankah ini sudah contoh yang cukup sederhana?
  • Penjelasan sederhana tidak selalu berarti implementasi sederhana. XKCD 1425 menggambarkan ini dengan baik. (Contoh: memeriksa apakah sebuah foto diambil di dalam taman nasional itu mudah, tetapi membedakan apakah itu foto burung memerlukan tim riset) xkcd 1425
• Saya merasa Rust cukup konsisten dan kohesif secara semantik. Dibanding bahasa lain, gula sintaks dan "sihir" semacam itu lebih sedikit sehingga terasa lebih intuitif. Semua interface biasanya mengikuti pola modul mem, jadi untuk benar-benar memahami struktur interface, sebaiknya mulai dari std::mem