Mungkin Rust Bukan Alat yang Cocok untuk Perangkat Lunak Ruang Pengguna dengan Konkruensi Skala Besar

• Artikel ini membahas tantangan dalam menggunakan Rust untuk perangkat lunak ruang pengguna dengan tingkat konkruensi yang besar.
• Model asinkron Rust dirancang untuk menangani dua konsep inti dalam komputasi modern: konkruensi dan paralelisme.
  • Paralelisme melibatkan menjalankan kode secara bersamaan di beberapa CPU.
  • Konkruensi melibatkan pemisahan masalah menjadi bagian-bagian independen yang dapat dijalankan tanpa bergantung pada urutan, atau dengan urutan parsial.
• Artikel ini menyoroti keterbatasan penggunaan banyak proses untuk konkruensi karena komunikasi antarp­roses yang mahal.
• Thread, yaitu proses yang berbagi memori yang sama, diajukan sebagai alternatif, tetapi dapat menimbulkan masalah kompleks seperti race condition dan deadlock.
• Makalah Tony Hoare tahun 1978, "Communicating Sequential Processes", mengusulkan penggunaan antrean atau channel agar thread dapat saling mengirim pesan, yang memberikan berbagai keuntungan seperti isolasi ala proses dan debugging yang lebih mudah.
• Pustaka standar Rust menyertakan channel di bawah std::sync::mpsc::sync_channel.
• Namun, untuk masalah yang menuntut tingkat konkruensi tinggi, seperti server web yang terhubung ke puluhan ribu pengguna, thread mungkin tidak memadai.
• Untuk situasi seperti ini, Rust menggunakan model "async/await", di mana fungsi yang ditandai asinkron mengembalikan future atau promise, lalu dapat ditunggu untuk menghasilkan hasil.
• Terlepas dari kelebihannya, Rust asinkron memiliki tantangan, seperti kebutuhan untuk meyakinkan compiler bahwa semuanya akan baik-baik saja. Hal ini bisa lebih sulit dibanding menggunakan thread mentah.
• Penggunaan "atomic reference counting" atau Arc diajukan sebagai solusi, tetapi bukan obat mujarab karena dapat menimbulkan masalah yang mirip dengan yang ada pada garbage collector.
• Artikel ini ditutup dengan gagasan bahwa, meskipun Rust memiliki kekuatan di area lain, Rust mungkin bukan alat yang optimal untuk perangkat lunak ruang pengguna dengan konkruensi skala besar.

[GN⁺]

Komentar Hacker News

• Penulis sedang mengembangkan klien metaverse berperforma tinggi di Rust yang harus memproses data dalam jumlah besar secara real-time.
• Proyek penulis menggunakan beberapa thread untuk berbagai tugas seperti rendering grafis, pemrosesan event jaringan, pemuatan aset, dan lainnya.
• Rust bermanfaat untuk proyek ini, dan penulis biasanya mengalami crash terkait memori setahun sekali karena kode "tidak aman" milik orang lain.
• Penulis mengkritik bahwa Rust memang tidak memiliki race condition, tetapi bukan berarti bebas deadlock, dan mengusulkan perlunya penganalisis deadlock statis.
• Penulis mengkritik luasnya penggunaan async di Rust, dengan alasan bahwa hal itu tidak cocok untuk pekerjaan yang terikat komputasi dan tidak kompatibel dengan thread yang berjalan pada beberapa prioritas.
• Penulis menyatakan bahwa kepemilikan tunggal Rust, meski merupakan kebutuhan umum bersama referensi balik, terlalu sulit untuk diimplementasikan.
• Penulis meyakini ekosistem game Rust belum siap untuk pengembangan game yang serius, dengan menyoroti kurangnya grafis non-mainan di Rust.
• Komentar lain setuju bahwa async Rust menantang dan sering kali tidak perlu, serta menyarankan bahwa pendekatan Go yang membuat semuanya sync dan hanya satu kanal async mungkin lebih baik.
• Beberapa komentator mengkritik luasnya penggunaan async dalam ekosistem Rust, dengan alasan bahwa hal itu memaksa program menjadi async sepenuhnya atau bergantung pada crate tokio untuk banyak hal.
• Beberapa komentator menyarankan bahwa fitur async Rust masih terus dikembangkan, sehingga terlalu dini untuk mengkritik kondisinya saat ini.
• Seorang komentator berpendapat bahwa Arc di Rust bukanlah sesuatu yang tidak diketahui, melainkan ditentukan oleh di mana dan bagaimana Anda memegangnya, dan menyarankan bahwa penulis sedang mencoba memaksakan model mental sebelumnya ke Rust.
• Beberapa komentator secara umum menentang penggunaan async/await, dengan alasan bahwa hal itu membelah bahasa dan ekosistem menjadi dua serta akan menimbulkan masalah jangka panjang.
• Seorang komentator menyarankan bahwa primitif yang tepat untuk konkurensi adalah Communicating Sequential Processes milik Hoare yang dipetakan ke green threads, seperti yang diterapkan di Java (sejak JDK17 - Java Virtual Threads), Go, dan Kotlin.
• Seorang komentator menyarankan bahwa menggunakan crate tidak aman seperti async-scoped untuk menangkap sebagian besar bug yang kemungkinan akan muncul jika ditulis dalam C++ adalah kompromi yang masuk akal.