Panduan Meratakan Kurva Belajar Rust

• Rust adalah bahasa yang menuntut cara berpikir yang sepenuhnya baru, dan pola pikir sangat memengaruhi kecepatan belajar
• Kuncinya adalah akrab dengan compiler; yang penting bukan sekadar memperbaiki pesan error, tetapi memahami alasannya
• Di tahap awal, tidak masalah banyak memakai clone(), unwrap, dan lain-lain agar bisa memulai dari hal kecil lalu merapikan secara bertahap
• Kita perlu banyak menulis kode dengan tangan dan membangun intuisi serta muscle memory melalui kesalahan dan trial-and-error
• Rust memiliki filosofi pengembangan yang berpusat pada sistem tipe, sehingga perlu membaca dokumentasi dengan saksama dan berlatih memodelkan dengan tipe

---

Flattening Rust's Learning Curve

Rust dikenal sebagai bahasa yang sulit dipelajari, tetapi tulisan ini memberikan saran yang konkret tentang sikap dan pendekatan agar belajar Rust menjadi lebih efektif, berdasarkan pengalaman penulis

Let Your Guard Down

• Rust menuntut mental model yang berbeda dari bahasa lain yang sudah ada
• Ada juga kasus ketika pemula belajar lebih cepat daripada ahli → sikap dan keterbukaan adalah kuncinya
• Borrow checker tidak seharusnya dianggap sebagai musuh, melainkan sebagai rekan penulis, dan kita perlu berusaha memahami pesan error-nya
• Penting untuk punya kemauan memahami secara mendalam mengapa compiler meminta parameter lifetime
• Semakin jelek dan rumit kode terlihat, semakin besar kemungkinan desainnya salah; jadikan itu pemicu untuk mencari cara yang lebih baik
• Verbosity Rust membantu untuk aplikasi berskala besar dan memudahkan refactoring
• Lint clippy sebaiknya diaktifkan dan dimanfaatkan semuanya sejak awal

Baby Steps

• Di awal, tidak masalah memakai String, clone(), unwrap dengan murah hati lalu melakukan refactoring nanti
• Daripada method chain yang rumit, mulailah dari if dan match yang sederhana
• Sebaiknya hindari async pada minggu pertama
• Belajar dengan mencoba potongan kode kecil di Rust Playground
• Latih satu konsep per satu file main.rs, dan anggap sebagian besar kode yang ditulis memang akan dibuang

Be Accurate

• Dalam Rust, ketepatan adalah syarat untuk bertahan
• Typo atau kesalahan kecil langsung bisa menjadi error kompilasi, jadi perlu sangat teliti
• Membiasakan diri otomatis menambahkan & dan mut bisa membantu
• Video streaming dari developer seperti Tsoding bisa menjadi referensi yang baik

Don’t Cheat

• Jika terlalu bergantung pada LLM atau code completion, proses belajar akan melambat
• Kita perlu mengetik sendiri dengan tangan, dan jika tidak paham, biasakan mencari di dokumentasi
• Jangan menulis kode dalam mode auto-pilot
• Terimalah kesalahan, dan gunakan itu untuk memahami cara kerja compiler
• Disarankan juga berlatih memprediksi apakah kode akan bisa dikompilasi sebelum menjalankannya
• Penting juga membiasakan diri membaca dan menganalisis kode orang lain
• Saat belajar, batasi penggunaan crate eksternal, dengan pengecualian seperti serde dan anyhow

Build Good Intuitions

• Konsep lifetime dan ownership lebih mudah dipahami jika divisualisasikan
• Disarankan membiasakan diri menggambar sendiri alur data dan arsitektur dengan alat seperti excalidraw
• Banyak engineer dan matematikawan hebat juga sangat memanfaatkan alat visualisasi

Build On Top Of What You Already Know

• Rust punya cara kerja yang berbeda bahkan untuk konsep yang terasa akrab (misalnya mut, pemindahan nilai, dan lain-lain)
• Namun, belajar dengan membandingkannya dengan bahasa yang sudah dikenal tetap bermanfaat

Contoh:

• Trait → mirip Interface, tetapi tidak sama
• Struct → terasa seperti class tanpa pewarisan
• Closure → mirip lambda
• Module → namespace
• Borrow → pointer dengan satu pemilik
• Option → Maybe monad
• Enum → algebraic data type

• Rosetta Code berguna untuk belajar dengan membandingkan kode lintas bahasa
• Belajar dengan mem-porting kode dari bahasa yang sudah dikenal ke Rust juga efektif
• Melatih diri memikirkan bagaimana idiom bahasa tertentu, seperti sintaks bawaan list atau perulangan, diekspresikan dalam Rust juga sangat baik

Don’t Guess

• Rust adalah bahasa yang tidak bisa ditebak-tebak
• Coba pikirkan alasan mengapa perlu menulis kode seperti "hello".to_string()
• Pesan error sangat informatif, jadi jangan pernah mengabaikan petunjuk yang tersembunyi di dalamnya
• Khususnya untuk error terkait borrow checker, kita perlu melacak alur data dengan tangan saat menganalisisnya

Lean on Type-Driven Development

• Rust adalah bahasa yang berpusat pada sistem tipe
• Banyak informasi bisa didapat dari function signature, definisi tipe, dan sebagainya
• Sering-seringlah membaca dokumentasi dan source code standard library
• Dengan merancang tipe terlebih dahulu lalu menulis kode yang sesuai, kita bisa membuat struktur yang lebih akurat dan dapat digunakan ulang
• Jika invariant diekspresikan melalui tipe, kode yang salah bahkan tidak akan bisa dikompilasi sejak awal

Invest Time In Finding Good Learning Resources

• Materi belajar Rust masih belum terlalu banyak, tetapi menemukan sumber yang cocok sejak awal sangat penting untuk menghemat waktu
• Alat belajar seperti Rustlings bisa terasa cocok atau tidak, tergantung preferensi masing-masing
• Sumber belajar berbasis pemecahan masalah, seperti Advent of Code dan Project Euler, bisa jadi lebih sesuai
• Video YouTube lebih baik dimanfaatkan sebagai hiburan daripada sumber informasi utama
• Cara yang paling efektif adalah membeli buku, membacanya secara offline, dan langsung menulis kode sendiri
• Jika memungkinkan, mengikuti pelatihan atau coaching dari ahli juga bisa sangat menghemat waktu dalam jangka panjang

Find A Coding Buddy

• Mengamati kode rekan yang andal seolah menjadi bayangannya juga merupakan cara yang baik
• Kita juga bisa berkembang dengan meminta code review atau ikut mereview kode di forum Rust, Mastodon, dan sebagainya

Explain Rust Code To Non-Rust Developers

• Menjelaskan Rust kepada orang yang belum mengenalnya juga efektif untuk belajar
• Disarankan juga berkontribusi pada kode open source yang tidak lagi terawat
• Menyusun glosarium yang memetakan istilah Rust ke dalam bahasa domain kerja sendiri juga sangat membantu

Believe In The Long-Term Benefit

• Rust adalah bahasa yang mengejar kualitas jangka panjang lebih daripada produktivitas jangka pendek
• Sulit menjadi mahir dalam semalam, tetapi fokus selama sebulan saja sudah bisa memberi banyak hasil
• Rust adalah bahasa Day 2; hari pertama memang berat, tetapi nilainya akan terus terasa jika dipakai secara konsisten
• Untuk berhasil, tidak cukup hanya belajar demi CV; kita perlu benar-benar menyukai kegiatan pemrograman itu sendiri

[aer0700]

Dulu saya pernah menulis ulang kode yang sebelumnya saya buat dalam C untuk tujuan belajar ke Rust, dan saya ingat betapa menyiksanya menangani pointer... Saya juga belum benar-benar bisa merapikan di kepala cara kerja rc atau refcell dan semacamnya...

[q8840]

Saya hanya pernah membaca dokumentasi dasar dan Nomicon masing-masing satu kali secara berurutan, lalu belum pernah sekali pun mentok saat mempelajari Rust, jadi saya merasa kurva belajarnya tidak setinggi itu.

[freedomzero]

Waduh, kalau sudah ketagihan unwrap dan clone, nanti bakal sangat menderita gara-gara ownership, hiks

[GN⁺]

Opini Hacker News

• Rasanya seperti membaca “A Discipline of Programming”; dulu cara Dijkstra menjelaskan secara nyaris moralistik memang diperlukan karena orang-orang belum benar-benar memahami konsep pemrograman itu sendiri. Penjelasan tentang ownership di Rust biasanya terlalu bertele-tele; sebagian besar konsep intinya sebenarnya ada, tetapi tersembunyi di bawah contoh-contoh. Di Rust, setiap objek data memiliki tepat satu pemilik. Ownership ini bisa dipindahkan agar selalu hanya ada satu pemilik pada satu waktu. Jika membutuhkan beberapa pemilik, maka pemilik sebenarnya haruslah sel dengan penghitungan referensi; sel ini bisa diduplikasi. Saat pemilik hilang, apa yang dimilikinya juga hilang. Dengan menggunakan referensi (ref), kita bisa meminjam akses ke objek data untuk sementara. Ownership dan referensi jelas berbeda. Referensi bisa diteruskan dan disimpan, tetapi tidak boleh hidup lebih lama daripada objeknya. Kalau tidak, akan menjadi error “dangling pointer”. Aturan-aturan ini ditegakkan secara ketat saat waktu kompilasi oleh borrow checker. Itulah model ownership Rust; setelah memahaminya, detail-detail lain pada akhirnya kembali ke aturan ini

  • Mungkin cuma saya, tapi penjelasan konsep seperti ini susah diikuti. Enkapsulasi juga terasa begitu; cuma dibilang menyembunyikan informasi tanpa menggali bagaimana/kenapa secara konkret. Misalnya, saya tidak paham siapa tepatnya pemilik di Rust. Apakah stack frame pemiliknya? Karena struktur LIFO, saya bertanya-tanya kenapa ownership dipindahkan ke callee; bukankah stack milik callee hilang lebih dulu, jadi mestinya tidak berbahaya? Kalau demi optimisasi, apakah ini supaya objek bisa dibersihkan lebih cepat? Kalau pemiliknya bukan stack frame, saya juga tidak tahu itu sebenarnya siapa. Saya juga bingung kenapa referensi mutable cuma boleh diberikan satu kali. Dalam lingkungan single-thread, toh fungsi lain tidak berjalan sebelum fungsi yang sekarang selesai, jadi rasanya dua-duanya menerima referensi mutable pun tidak masalah. Kalau masalahnya hanya muncul di lingkungan multithread, kenapa tidak error saat itu saja? Pertanyaan-pertanyaan seperti ini yang membuat saya berkali-kali menyerah saat mencoba belajar Rust

  • Ini bukan penjelasan ownership, melainkan penjelasan yang memotivasi. Bagian tersulit dan paling inti adalah bagaimana membaca lifetime yang rumit dan saling terkait dalam signature fungsi, serta bagaimana memahami dan memperbaiki error compiler yang muncul saat memanggil fungsi seperti itu

  • Membuat ringkasan yang terlihat benar dan sempurna bagi orang yang sudah tahu konsep-konsep ini jauh lebih mudah daripada menjelaskannya kepada orang yang baru belajar. Kalau dijelaskan seperti ini, apakah orang yang hanya pernah memakai call-by-sharing akan langsung paham? Rasanya tidak

  • Orang yang tidak tahu Rust, setelah membaca ringkasan ini saja, tetap tidak akan tahu apa-apa tentang Rust. Yang muncul malah kesan, “bahasa ini seolah punya black magic di dalam compilernya”

  • Konsep ownership dan borrowing sendiri mudah dipahami. Yang benar-benar membuat Rust sulit dipelajari adalah bahwa signature fungsi dan kode pemakaian nyatanya harus saling membuktikan bahwa referensi tidak hidup lebih lama daripada objeknya. Sebagai catatan, tidak menyimpan objek yang direferensikan ke dalam tipe biasanya pilihan yang lebih baik karena membuat pembuktiannya lebih sederhana

  • Saya sudah lama mencari tulisan tentang bagaimana orang-orang di tahun 60-an menangani state sistem/aplikasi pada level assembly. Katanya paper Sketchpad milik Sutherland punya banyak detail soal struktur data, tapi saya baru membaca bab 2-3 saja

  • Penjelasan ini tidak terasa bermakna bagi saya. Ownership dan borrowing tidak didefinisikan dengan jelas. Keduanya tampak seperti istilah berbasis metafora yang diambil dari pengelolaan aset finansial. Saya tidak terbiasa dengan Rust, tetapi pemilihan istilah seperti ini justru terasa membuat konsepnya lebih sulit dipahami. Metafora sering jadi pedang bermata dua. Mungkin akan lebih membantu kalau dijelaskan dengan istilah yang lebih langsung terkait memori

  • Penjelasannya sama sekali melewatkan perbedaan penting antara peminjaman eksklusif/bersama (atau mutable/immutable) dalam model ini. Rust membuat banyak pilihan tentang bagaimana borrowing semacam ini diizinkan, dan itu tidak intuitif. Misalnya, aturan no aliasing bukan lahir dari intuisi, melainkan demi optimisasi fungsi. Bagian paling rumit dari borrowing adalah bahwa karena aturan lifetime elision, pesan error compiler kadang menunjuk ke tempat yang tidak ada hubungannya dengan penyebab sebenarnya. Aturan elision ini sendiri tidak intuitif dan merupakan pilihan yang diperkenalkan demi penyederhanaan

  • Versi revisi Rust Book dari Brown University menjelaskan borrow checker dengan sangat baik

  • Penjelasannya terasa tidak lengkap; misalnya, tidak ada penjelasan tentang apa yang terjadi kalau pihak yang meminjam hilang

  • Ada kalimat “pemilik sebenarnya haruslah sel dengan penghitungan referensi”, tapi penjelasannya terasa hanya bisa dipahami oleh orang yang sudah tahu apa itu

  • Saya baru benar-benar paham borrow checker setelah mencoba mengimplementasikan borrow checker saya sendiri

  • Butir kedua di bagian kedua sangat berlebihan. Dalam praktiknya, ada sangat banyak kasus kode yang aman tetapi tidak bisa dikompilasi oleh Rust. Kompleksitas ini muncul untuk memperjelas batas tentang apa yang bisa dibuktikan compiler

• Model ownership Rust, lifetime, enum, dan pattern matching terasa sangat membebani saat pertama kali ditemui. Pada percobaan pertama saya terlalu cepat kewalahan, lalu pada percobaan kedua saya mencoba membaca setiap baris buku dan kesabaran saya habis. Di tengah itu saya menyadari bahwa Rust adalah bahasa yang memberi wawasan lebih dalam tentang pemrograman dan desain perangkat lunak. Baru pada percobaan ketiga saya mulai belajar dengan menulis ulang program-program kecil dan skrip yang dulu pernah saya buat ke dalam gaya Rust; dalam prosesnya saya juga mempelajari error handling yang khas Rust, representasi data dengan memanfaatkan tipe secara aktif, pattern matching, dan sebagainya. Setelah pengalaman itu, saya yakin belajar Rust adalah salah satu keputusan terbaik dalam hidup saya sebagai programmer. Mendefinisikan tipe, struct, dan enum sejak awal, lalu menulis fungsi berdasarkan data immutable dan pattern matching, kini terasa alami juga saya terapkan di bahasa lain

  • Saya punya pengalaman serupa. Baru saat belajar Rust untuk ketiga kalinya saya mulai benar-benar merasa paham, dan bisa menulis beberapa program secara efektif. Meski pengalaman pemrograman saya sudah lama, kadang tetap perlu belajar berulang. Dulu saat mencoba memahami Dagger, framework dependency injection di JVM, saya juga butuh tepat tiga kali percobaan belajar. Mungkin ini memang pola umum bagi saya saat mempelajari hal yang kompleks

  • Ini fenomena yang sering terlihat saat developer C++ pertama kali mencoba Rust; kalau masih memakai cara pikir C++, mereka akan terus berkelahi dengan “borrow checker”. Begitu benar-benar memahami idiom Rust, mereka kemudian membawa kembali kebiasaan itu ke C++ dan menulis kode yang lebih tangguh, meski C++ sendiri tidak punya borrow checker

• Nasihat seperti “baca seluruh kode dengan teliti sebelum compile dan perbaiki typo” terasa aneh buat saya. Compiler Rust terkenal dengan pesan error yang sangat ramah, jadi kenapa saya harus duduk mencari typo sendiri? Saya ingin komputer yang menangkap typo saya

  • cargo fix memang bisa memperbaiki sebagian masalah secara otomatis, tapi tidak semuanya

• Ada nasihat seperti “jangan melawan”, “kalau mau belajar buang dulu keangkuhan”, “perlu deklarasi menyerah”, “resistensi itu sia-sia, kalau tidak cepat menerima hanya akan memperpanjang penderitaan”, dan “lupakan apa yang sudah kamu tahu”. Membaca ini membuat saya merasa seolah OS teleskrin Orwell ditulis dengan Rust

  • Saya setuju dengan ini. Kesalahan terbesar yang membuat saya frustrasi saat belajar Rust adalah mencoba memaksanya ke paradigma object-oriented. Begitu saya menerima saja dan mencoba melakukannya seperti yang Rust inginkan, semuanya langsung lebih lancar

• Rust punya hambatan yang cukup besar bagi pemula; ia sangat berbeda dari bahasa lain — ini memang disengaja, tapi sekaligus jadi penghalang masuk. Sintaksnya rumit dan sangat padat, sampai kadang terlihat seperti papan ketik ditekan pakai siku. Satu karakter bisa sepenuhnya mengubah makna, dan tingkat penyarangannya tinggi. Banyak fiturnya sulit dipahami tanpa latar belakang teoretis, sehingga kompleksitasnya terasa jauh lebih besar; sistem tipe dan mekanisme borrowing adalah contoh utamanya. Bagi pengguna Python atau JavaScript pada umumnya, ini nyaris seperti bahasa alien. Di zaman ketika sebagian besar programmer praktis tidak punya latar belakang CS setingkat magister, Rust rasanya kurang cocok. Ditambah lagi makro membuatnya jauh lebih rumit; kalau tidak tahu definisinya, sulit memahami arti kode tersebut. Akhir-akhir ini saya berharap LLM bisa menurunkan hambatan ini. Saya sendiri masih belum merasa perlu belajar Rust sekarang, tapi berkat LLM saya bersedia mencobanya lagi suatu hari nanti. Memang Rust adalah bahasa yang unik sulitnya untuk dipelajari

  • Bagian yang paling menyulitkan saya saat belajar Rust memang makro. Materi yang saya pakai memasukkan makro terlalu awal tanpa penjelasan, dan itu membuat bingung

• Dalam situasi apa pun rasanya selalu ada pilihan yang lebih baik daripada Rust. Meski begitu saya tetap berpikiran terbuka. Mungkin suatu saat nanti saat Rust sudah cukup umum, barulah itu akan bermakna

  • Jika tetap sesuai tujuan awal saat Rust pertama kali dirancang hampir 20 tahun lalu, maka ini adalah bahasa yang sempurna untuk membangun ulang browser dari nol. Sekarang Rust memang sudah dominan di ranah ini. Dan “unix” milik pencipta bahasa itu tidak pernah menaklukkan dunia lalu digantikan oleh sesuatu seperti Ladybird buatan orang lain

• Kalau sampai perlu ada tulisan yang meyakinkan orang bahwa sebuah bahasa layak dipelajari dengan susah payah, saya jadi curiga jangan-jangan masalahnya memang ada pada desain bahasanya sendiri. (Saya belum belajar Rust, jadi jangan dianggap terlalu serius)

  • Komentar Anda hanya bisa saya baca sebagai “kalau sulit berarti tidak layak dilakukan”. Semua hal punya kelebihan dan kekurangan; apakah keberadaan kekurangan saja berarti tidak layak bahkan untuk dicoba? Kalau ada orang menulis dengan penuh semangat bahwa memainkan harpa itu sulit, apakah berarti bermain harpa adalah hobi yang buruk?

  • Saat sudah menjadi developer senior, kadang kita baru sekilas melihat pelajaran yang dianggap penting oleh Rust tanpa benar-benar merasakannya. Banyak orang berpikir, “Saya sudah pakai bahasa dengan garbage collection, apa lagi yang bisa diajarkan Rust?” Padahal ketika mutabilitas dan shared reference saling terkait, kekacauan besar bisa muncul, dan karena itu banyak orang akhirnya memakai immutable object. Begitu punya immutable object, mereka lalu mencari cara supaya objek itu tetap bisa diubah dengan nyaman, dan hasilnya justru bisa kurang praktis dibanding mutable object. Saat mencoba mengekspresikan bahwa “objek ini punya fase saat bisa diubah dan fase saat immutable”, akhirnya muncullah kebutuhan akan borrow checker. Ketika borrow checker masuk, pertanyaan berikutnya menjadi “kalau begitu kenapa masih perlu garbage collection?” Pada akhirnya garbage collection dipakai hanya karena orang malas memahami lifetime objek secara jelas. Rust memaksa kita mengalami langsung pertanyaan-pertanyaan mendasar seperti ini

  • Keputusan desain Rust sering sulit dipahami. Mojo juga punya borrow checker, tetapi jauh lebih mudah dipelajari daripada Rust karena beberapa pilihan desain. Pertama, ada value semantics. Di Rust, pemula sering disuruh pakai clone(), padahal di banyak bahasa statis biasa (C, C++, Go, dan lain-lain), value semantics adalah bawaan umum. Kedua, lifetime di Mojo bukan tentang apakah nilai masih bisa dipakai berdasarkan scope, melainkan menentukan kapan nilai dihapus. Jika masih ada referensi, lifetime diperpanjang, dan begitu pemakaian selesai, nilainya langsung dihapus. Karena itu di Mojo kita tidak perlu melihat error seperti “nilai tidak hidup cukup lama”. Dua pilihan desain ini saja sudah sangat mengurangi bebannya

  • Bagi pemula, bahasa apa pun memang sulit dipelajari, jadi Rust tidak bisa dibilang istimewa dalam hal itu. Pemrograman memang pada dasarnya punya learning curve

  • Menurut saya keberadaan tulisan seperti ini lebih banyak mengatakan sesuatu tentang penulisnya daripada tentang bahasanya. Bukan mengkritik penulis; saya justru menganggap keren semangat seperti ini dibagikan

  • Tulisan ini terasa lebih banyak membahas learning curve Rust daripada masalah apa yang diselesaikan Rust. Keduanya perlu dijelaskan dengan seimbang agar orang bisa menyimpulkan apakah tantangan itu memang layak dijalani

  • Perdebatan desain soal Rust tentu bisa saja dilakukan, tetapi sulit menilai bahasa Rust itu sendiri hanya dari fakta bahwa tulisan seperti ini perlu ada. Justru saya merasa Python lebih membutuhkan tulisan semacam ini. Karena makin banyak programmer yang bukan berlatar belakang engineering, Python secara paradoks menjadi bahasa yang bisa dipakai siapa saja sementara Rust tidak. Bagi sebagian orang, Rust jauh lebih mudah dipelajari dibanding bahasa seperti C atau Zig. Saya juga suka Python, tetapi saya sadar itu pada dasarnya bahasa yang mengerikan. Bahkan di era LLM, orang-orang tampaknya belum terlalu sadar bahwa mereka seharusnya menulis Python yang teroptimasi; teman AI kita pun, kalau tidak diarahkan, akan terus menghasilkan Python yang tidak efisien

  • Untuk pertanyaan “bukankah itu masalah desain bahasa?”, respons saya adalah “kenapa?”

  • Sebagai orang yang sudah belajar Rust, saya bisa bilang bahwa meski saya kebanyakan memakai Python, saya tidak pernah merasa Rust punya cacat bahasa. Justru karena ini bahasa yang sangat ketat, semakin kita mencoba membuatnya tidak terasa seperti Rust, semakin banyak penderitaan yang muncul. Kalau mengikuti gaya Rust, makin kompleks programnya justru makin terasa membantu. Di bahasa lain, error biasanya ditemukan satu per satu saat runtime, sedangkan di Rust hampir semuanya tertangkap saat waktu kompilasi. Tentu ini tidak mencegah error logis, tetapi integrasi pengujiannya yang kuat membantu menanganinya. Rust memang punya kekurangan, tetapi tetap sangat layak dipelajari setidaknya sekali. Cara Rust mengurangi error juga bisa dijadikan kebiasaan pengembangan yang baik di bahasa lain

  • Memang benar Rust terlalu kompleks sehingga LLM sulit langsung menghasilkan kode Rust yang benar dalam sekali jalan. Meski begitu, menurut saya itu tetap jauh lebih baik daripada berbagai masalah di JavaScript atau bahasa lain yang lemah/bersifat dinamis

  • Saya sudah belajar Rust dan saya paham maksud Anda. Rust memang benar-benar kompleks dan terasa seperti bahasa hasil “desain komite”. Tooling-nya keren, dan tetap lebih tidak rumit dibanding C++, tetapi jelas bukan bahasa yang mudah dipelajari

  • Masalah tulisan seperti ini adalah tidak menyentuh inti persoalannya. Ada program-program yang memang sejak awal tidak diizinkan Rust untuk ditulis. Ada alasan yang kuat untuk itu, tetapi ini secara fundamental berbeda dari hampir semua bahasa yang biasa dipakai orang. Jelas ada program yang tidak bisa ditulis dalam Rust, jadi itu harus diterima; kalau tidak, Rust memang tidak cocok

• Salah satu pendekatan yang jarang dilakukan saat belajar Rust adalah mempelajari dulu hanya sebagian dari bahasanya. Misalnya, buku pengantar Rust yang saya pakai sama sekali tidak mengajarkan lifetime. Dengan hanya fungsi-fungsi tanpa lifetime pun, kita sudah bisa menulis cukup banyak program yang benar-benar bekerja. Hal yang sama berlaku untuk makro; memang tidak mudah, tetapi tetap saja lebih baik belajar subset-nya lebih dulu. Dan saya juga merasa pendekatan yang lebih tepat adalah belajar konsep borrowing dulu, bukannya dari awal hanya bergantung pada copy() atau clone(). Borrowing adalah inti dari bahasa ini

• Satu-satunya cara agar saya mau belajar Rust adalah kalau mulai banyak lowongan dengan gaji di atas 300 ribu dolar per tahun. Saya juga melihat Rust punya potensi menggantikan C++ di bidang quant ke depan. Tapi OCaml sudah ada, dan kalau saya harus belajar bahasa yang sangat sulit dan rumit, setidaknya saya ingin melihat uangnya dulu. Sejauh ini pekerjaan bergaji tertinggi yang saya lihat justru Python

• Melihat komentar-komentar ini, saya jadi sadar akan sikap yang sering muncul pada programmer lama ketika mereka dikoreksi. Semakin lama bekerja, semakin mudah menjadi keras kepala. Mungkin ada baiknya masing-masing merenungkan sendiri kenapa saran compiler begitu ditolak, apa yang sebenarnya ingin dilakukan secara berbeda, dan apa tepatnya yang menghalanginya