Jika Rust Ditulis Ulang

 (josephg.com)
1 poin oleh GN⁺ 2024-09-27 | 1 komentar | Bagikan ke WhatsApp
  • Rust berangkat dari kesadaran masalah bahwa, meskipun memiliki keunggulan keamanan memori, performa, tipe aljabar, dan Cargo, evolusi bahasa di kanal stabil melambat sehingga terasa seperti “produk generasi pertama yang belum selesai”
  • Setelah komunitas membesar, pengambilan keputusan berbasis konsensus menjadi bottleneck, dan fitur yang sudah diimplementasikan seperti coroutine terus menumpuk karena belum bisa digunakan lama di stable Rust
  • “seph edition” yang hipotetis adalah gagasan untuk mempertahankan ekosistem Rust dan Cargo yang ada, sambil mengizinkan breaking change untuk bereksperimen dengan sistem efek, izin compile-time, borrow field struct, comptime, dan lainnya
  • Untuk mengurangi risiko rantai pasok, fitur sensitif seperti penulisan file, jaringan, FFI, dan unsafe perlu diberi capability, dan pemanggil harus mengizinkannya secara eksplisit
  • Sebagian besar usulan tidak kompatibel dengan Rust yang ada, dan menambahkan capability saja menciptakan kondisi kegagalan baru yang memecahkan kompatibilitas semver, sehingga diperlukan edition baru atau fork compiler

Mengapa Rust terasa seperti “produk generasi pertama”

  • Pada awalnya Rust terasa sangat menarik berkat tipe aljabar, keamanan memori tanpa kehilangan performa, dan package manager modern
  • Setelah digunakan sekitar 4 tahun, bahasanya terasa seperti selalu berada dalam keadaan “sedikit kurang”
  • Keluhan utamanya adalah frekuensi fitur baru masuk ke stable Rust menurun, dan laju evolusi bahasa juga melambat tajam
  • Rust unstable book memiliki sekitar 700 fitur unstable, dan banyak di antaranya adalah perubahan standard library
  • Coroutines adalah fitur dengan RFC yang sudah berusia 7 tahun dan sudah diimplementasikan di compiler, tetapi pengguna stable Rust masih belum bisa memakainya
  • Proses RFC Rust terlihat seperti ruang tempat ide bagus berdiam terlalu lama
    • Diskusi perbaikan Mutex disebut sebagai contoh: 25 orang meninggalkan lebih dari 200 komentar selama 2 tahun, tetapi tidak mencapai kesimpulan yang jelas

Gagasan “seph edition” hipotetis

  • Yang dibayangkan adalah mem-fork compiler, tetapi membiarkan kode Rust yang ada tetap apa adanya, lalu menambahkan “seph” sebagai Rust edition terpisah
  • Di edition ini, breaking change diizinkan, tetapi selama compiler tetap bisa mengompilasi mainline Rust, crate Cargo yang ada tetap bisa digunakan
  • Ada lima poros besar yang ingin diubah
    • Function trait dan sistem efek
    • Capability compile-time
    • Perancangan ulang Pin, move, dan borrow struct
    • comptime ala Zig
    • Perbaikan kecil pada sintaks dan standard library

Function trait dan sistem efek

  • Rust memiliki trait untuk struct, tetapi usulannya adalah fungsi juga harus bisa diberi trait/effect yang lebih kaya
  • Atribut yang bisa dimiliki fungsi dirangkum sebagai berikut
    • Apakah bisa panic
    • Apakah ukuran stack tetap
    • Apakah dieksekusi sampai selesai, atau melakukan yield atau await
    • Tipe continuation saat berupa coroutine
    • Apakah merupakan fungsi murni
    • Apakah secara tidak langsung menjalankan kode unsafe
    • Apakah terminasi dijamin
  • Jika parameter dan return type fungsi diekspos seperti associated type untuk fungsi, referensi tipe yang saat ini mustahil di stable Rust menjadi mungkin
  • Contohnya adalah kode yang langsung menamai return type fungsi seperti some_iter::Output dan memasukkannya ke field struct
  • Ketika dibutuhkan jaminan bahwa blok kode tertentu tidak akan pernah panic, seperti di Linux kernel, penanda seperti #[disallow(Panic)] dapat dipakai untuk memeriksa kemungkinan panic termasuk pada pemanggilan rekursif
  • Compiler sudah menangani trait terkait fungsi seperti Fn, FnOnce, dan FnMut, tetapi bentuk saat ini dinilai terlalu miskin
  • Sebagai referensi lebih rinci, ditautkan tulisan dan presentasi Yoshua Wuyts tentang effect system

Mengurangi risiko rantai pasok dengan capability compile-time

  • Sebagian besar proyek Rust mengambil banyak crate pihak ketiga, dan crate utilitas kecil pun bisa menciptakan risiko rantai pasok lewat update berbahaya
  • Seperti unsafe yang merupakan opt-in eksplisit dalam keamanan memori, fitur sensitif terkait filesystem, jaringan, FFI, dan raw pointer juga harus diizinkan secara eksplisit
  • Diusulkan pendekatan memberi marker tag pada fungsi standard library yang sensitif secara keamanan
    • Contoh: std::fs::write(path, contents) menulis file ke path arbitrer, sehingga memiliki tag seperti #[cap(fs_write)]
    • Compiler secara otomatis men-taint seluruh call tree yang memanggil fungsi tersebut
  • Jika crate pihak ketiga membutuhkan capability fs_write, pemanggil harus mengizinkannya secara eksplisit lewat Cargo.toml atau anotasi di titik pemanggilan
  • Jika tidak diizinkan, compiler dapat menghasilkan error bahwa foo::do_stuff() menulis ke filesystem lokal, tetapi crate foo belum dipercaya untuk capability tersebut
  • Banyak crate utilitas seperti human-size atau serde tidak membutuhkan capability khusus, sehingga meskipun penulis menambahkan kode berbahaya, tindakan menulis file atau jaringan dapat dicegah pada tahap kompilasi
  • Alternatifnya adalah mengubah API sensitif agar menerima parameter Capability terpisah
    • Contoh: std::fs::write mengharuskan nilai FsWriteCapability
    • Pembuatan objek Capability dibatasi agar hanya mungkin dari root crate
  • Pendekatan ini menambah boilerplate, tetapi lebih fleksibel, dan perlakuan serupa juga diperlukan untuk skrip build.rs dan blok unsafe
  • Bahkan dalam situasi crates.io diretas lalu kode cryptolocker dimasukkan ke serde, dengan pendekatan capability, error kompilasi akan terjadi sebelum kode tersebut berjalan di banyak mesin developer atau disertakan dalam binary

Perancangan ulang Pin, move, dan borrow struct

  • Pin adalah hack rumit untuk memutar celah borrow checker, dan dinilai sebagai band-aid yang muncul karena ingin mempertahankan kompatibilitas mundur
  • Yang sebenarnya dibutuhkan dianggap lebih dekat dengan marker trait Move untuk menandai tipe yang bisa dipindahkan
  • Saat ini Rust tidak memiliki trait Pin, melainkan Unpin dan !Unpin, dan bentuk negasi ganda ini membuat konsepnya lebih sulit
  • Ada kritik bahwa karena Pin hanya diterapkan pada tipe referensi, kode yang membungkus dengan Box muncul di banyak tempat
    • Sebagai contoh, ditautkan helper library seperti Tokio stream wrapper, ouroboros, async-trait, dan self_cell
  • Fungsi yang menerima nilai pinned seperti Future::poll(self: Pin<&mut Self>, ..) juga menjadi rumit, dan dibutuhkan crate terpisah untuk menangani projection
  • Di dalam fungsi, borrow checker mengelola variabel dalam status “owned”, “borrowed”, atau “mutably borrowed”, tetapi status ini tidak terlihat langsung oleh programmer
  • async fn membuat compiler menghasilkan hidden struct untuk menyimpan status suspend, dan pada saat itu dapat muncul bentuk satu field mem-borrow field lain
  • Rust tidak memiliki sintaks untuk menyatakan bahwa field struct berada dalam borrowed state, dan lifetime antar-field juga tidak bisa dinyatakan langsung
  • Arah yang diusulkan adalah memperluas borrow checker agar borrow field struct dapat ditulis langsung
    • Contoh: sintaks “local borrow” seperti y: &'Self::x Vec<usize>
    • Compiler mengetahui bahwa x sedang di-borrow dan menerapkan batasan yang sama seperti variabel borrowed di dalam fungsi
  • Sintaks seperti ini juga dapat digunakan untuk menangani self-referential struct atau bentuk seperti source: String dan ast_nodes: Vec<&'Self::source str> pada AST
  • Struct yang memiliki borrowed field tidak bisa dipindahkan, sehingga tidak akan mengimplementasikan Move; lebih jauh, trait Mover untuk berpindah sendiri secara aman juga dipertimbangkan

comptime ala Zig dan masalah macro Rust

  • Compiler Rust pada dasarnya terlihat seperti struktur yang menangani beberapa bahasa sekaligus: Rust, bahasa macro Rust, hingga proc macro
  • Penilaian utamanya adalah Rust sendiri bagus, tetapi bahasa macro-nya tidak bagus
  • comptime di Zig adalah cara compiler menjalankan sebagian kode pada waktu kompilasi lewat interpreter kecil
  • Fungsi, parameter, if, dan loop dapat ditandai sebagai kode compile-time, sementara kode non-comptime di-emit ke program sebenarnya
  • std print case study dari Zig adalah contoh yang menerima format string sebagai parameter comptime, lalu mem-parsingnya dalam loop comptime untuk menghasilkan kode output
  • Implementasi println!() Rust memanggil fungsi internal seperti format_args_nl, dan fungsi ini diduga di-hardcode di compiler
  • Kritik berlanjut bahwa bahkan penulis compiler Rust tampaknya tidak ingin menggunakan bahasa macro Rust

Usulan perbaikan kecil pada sintaks dan standard library

  • Ada poin bahwa masalah Range<T> mengimplementasikan Copy ketika T: Copy ingin diperbaiki
  • Masalah derive dengan associated type juga disebut sebagai target perbaikan
  • Ada usulan bahwa ekspresi if let harus mendukung logical AND
    • Bentuk yang diinginkan: if let Some(x) = some_var && some_expr { }
    • Workaround saat ini adalah tuple matching (some_var, check_foo()), tetapi meskipun some_var adalah None, check_foo() tetap dijalankan, berbeda dari perilaku short-circuit pada if biasa
    • Contoh: Playground
  • Ergonomi raw pointer juga disebut sebagai target perbaikan
    • Pada referensi, myref.x bisa dipakai, tetapi pada pointer harus ditulis seperti (*myptr).x atau (*(*myptr).p).y
    • Posisinya adalah kode unsafe harus dibuat semudah mungkin untuk dibaca dan ditulis
  • Ada usulan untuk mengubah built-in collection type agar menerima Allocator secara eksplisit di constructor, bukan memakai allocator global
  • async juga perlu diperbaiki, tetapi dibiarkan karena materinya cukup banyak untuk tulisan terpisah

Kompatibilitas dan kelayakan eksekusi

  • Sebagian besar usulan tidak kompatibel dengan Rust yang ada
  • Penambahan capability keamanan pun menciptakan kondisi kegagalan baru yang membuat crate memecahkan kompatibilitas semver, sehingga membutuhkan Rust edition baru
  • Beberapa tahun lalu, mungkin penulis akan membuat RFC, tetapi ia ingin menghindari situasi di mana gagasan itu menjadi satu lagi ide yang tidak terwujud setelah melalui proses panjang komentar RFC GitHub
  • Pada akhirnya, bayangan itu kembali ke ide mem-fork compiler sendiri, tetapi masih ada kendala realistis bahwa terlalu banyak proyek yang harus dikerjakan

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-27
Pendapat di Hacker News

  • Berlawanan dengan anggapan bahwa proses RFC Rust adalah kuburan bagi ide-ide bagus, saya rasa tim inti Rust memang berada di arah yang benar dengan membuat penambahan fitur baru ke bahasa pemrograman ini menjadi sulit
    Permukaan bahasa harus dijaga agar tidak membengkak, tidak konsisten, dan tidak dapat diprediksi. Awalnya saya juga menyukai Swift, tetapi akhirnya menyerah karena hal-hal seperti nama fungsi duplikatif semacam isMultiple(of:), aturan parsing kurung kurawal untuk SwiftUI, aturan tipe referensi/nilai dan mutabilitas, serta notasi singkat argumen closure terus bertambah. Ide bagus itu banyak, jadi saya berharap Rust dijaga tetap ramping semaksimal mungkin

    • Saya penulis artikel aslinya. Saat memakai Rust, sering ada celah di mana fitur X dan fitur Y masing-masing didukung, tetapi tidak bisa dipakai bersama
      Misalnya, fungsi yang mengembalikan impl Trait bisa digunakan dan struct bisa memiliki field arbitrer, tetapi nilai yang dikembalikan sebagai impl Trait tidak bisa dimasukkan ke field struct. Sebabnya, tipe itu tidak bisa diberi nama. if a && b bisa, dan if let Some(x) = x juga bisa, tetapi if let Some(x) = x && b tidak bisa. Hal-hal seperti ini sebaiknya diperbaiki. Dari sisi jumlah baris kode compiler, Rust memang akan membesar, tetapi dari sisi kompleksitas untuk dipelajari dan digunakan, celah fitur seperti ini justru membuat bahasa menjadi lebih kompleks. Pin bukan pekerjaan besar untuk diimplementasikan di standard library, tetapi sama sekali bukan fitur yang ramping, dan beban kognitifnya sangat besar. Menurut saya, daripada compiler yang sederhana tetapi bahasanya sulit dipakai, lebih baik borrow checker yang kompleks dengan kode Rust yang mudah dibaca
    • Menulis RFC lebih mudah daripada mengimplementasikannya, dan orang yang bisa menulis RFC juga lebih banyak. Karena itu, pada tingkat popularitas apa pun, antrean RFC mau tidak mau akan terlihat seperti kuburan ide-ide bagus
      Bahkan seandainya 100% ide yang mengantre diterima dan akhirnya dikerjakan, perbedaan antara laju masuk dan laju keluar akan membuatnya tetap terlihat begitu. Kalau ingin melampaui para penulis RFC, lebih baik jangan menulis RFC; buatlah implementasi siap produksi yang dilengkapi dokumentasi dan pengujian, serta bisa digabungkan dengan rapi ke tree
    • Secara umum saya setuju, tetapi generic associated constants pada trait berada dalam keadaan paradoks: sudah distabilkan, tetapi tidak bisa digunakan seperti konstanta sungguhan
      Tidak bisa dipakai sebagai const generic untuk tipe lain, juga tidak bisa dipakai sebagai panjang array. Kalau hanya butuh nilai, kita bisa mendefinisikan fungsi untuk mengembalikannya, jadi saat ini tidak terlalu berguna. Jika didukung dengan benar, crate pendukung seperti generic_array dan typenum di library kriptografi bisa dihilangkan. Meski begitu, saya tetap setuju bahwa tim Rust harus berhati-hati dalam menambahkan fitur
    • Rust, di antara bahasa pemrograman yang sudah cukup arus utama, sudah berada dalam kondisi seperti wagyu, jadi jangan sampai ditambahi lemak lagi hingga tidak bisa dimakan
    • Ide bagus, menurut definisinya, adalah sesuatu yang langka dan berharga

  • Situasi dependensi cukup serius, tetapi tampaknya tidak banyak orang yang mau mengakuinya. Contoh yang baru-baru ini saya lihat adalah crate cargo-watch
    Intinya ini aplikasi sederhana yang memantau perubahan file dan menjalankan ulang compiler, dan implementasinya bahkan tidak sampai 1.000 baris. Namun jika dependensinya di-vendor, kode Rust-nya membengkak hingga hampir 4 juta baris di lebih dari 8.000 file. Itu berlebihan untuk sekadar pemantau file sederhana
    https://crates.io/crates/cargo-watch

    • Kalau dependensi transitif mudah dibuat, dan ada budaya bahwa “kalau ada library, harus dipakai”, hasilnya pasti begitu
      C/C++ hampir satu-satunya contoh di antara bahasa yang banyak dipakai di mana package manager ala npm tidak populer, sehingga kebanyakan library bersifat mandiri atau dependensinya sedikit dan sering kali opsional. efsw adalah pemantau sistem file C++ 7.000 baris tanpa dependensi. Library single-header dari dunia pemrograman game seperti stb_*, cgltf, dan Dear ImGui termasuk yang paling nyaman yang pernah saya pakai. Menurut saya, package manager baru mungkin secara keseluruhan akan diuntungkan oleh larangan dependensi transitif. Dependensi pada library besar bisa dibuat agar diinstal langsung oleh pengguna, disediakan sebagai callback, atau dijadikan fitur standar
      https://github.com/SpartanJ/efsw
      https://github.com/nothings/stb
      https://github.com/jkuhlmann/cgltf
      https://github.com/ocornut/imgui
    • Sekarang ini rimba dependensi adalah cara umum untuk menyelesaikan pekerjaan. Hal terbaik yang bisa dilakukan runtime adalah menerimanya, membuatnya secepat dan seaman mungkin, serta memperluas standard library agar proyek dengan dependensi minimal pun tetap didukung
      Menurut saya, pemantau file sama sekali tidak sederhana, terutama jika mendukung banyak platform
    • Ini fenomena yang wajar dan tidak terlalu menakutkan. Semua kode berdiri di atas pegunungan dependensi yang memuat jauh lebih banyak fungsi daripada yang benar-benar dipakainya
      Sebagian dari cargo watch menarik library wrapper Win32 API, yang merupakan binding hasil auto-generation untuk panggilan Win32 sehingga memang pasti besar. Standard library di kebanyakan bahasa juga berisi jutaan baris, dan aplikasi hanya memakai sebagian kecil darinya. Boost di C++ juga sangat besar, tetapi developer hanya mengambil sebagian ekstensi yang diperlukan. Dibanding neraka ala npm di mana satu paket seperti isOdd atau is even bisa merusak ekosistem, lebih baik punya lebih sedikit dependensi besar yang dipelihara dan diandalkan banyak orang; Rust pada umumnya lebih dekat ke arah itu
    • Di tempat kerja saya secara sadar menghapus dan menulis ulang berbagai dependensi, tetapi baik 1.000 baris maupun 4 juta baris tampaknya sama-sama tidak akurat sebagai estimasi jumlah baris kode yang tepat untuk proyek ini
      Sebagian besar dependensi cargo-watch tampaknya berasal dari tiga kebutuhan langsung: clap, cargo_metadata, dan watchexec. clap membawa banyak elemen CLI spesifik platform, dan cargo_metadata mau tidak mau membawa banyak hal dari keluarga serde. watchexec masih bisa diperbaiki: ia bergantung pada command-group yang dikelola organisasi yang sama, dan itu secara wajib membutuhkan Tokio. Masalah yang lebih besar adalah sulitnya memperbaiki dependensi berlebihan pada crate lain. Jika ada crate yang terikat pada watchexec lama, kadang masih bisa disesuaikan lewat Cargo.lock, tetapi biasanya sulit dan harus diakali dengan [patch]. Akan bagus jika ada cara mudah untuk mendefinisikan “stand-in” sebagai pengganti crate versi tertentu, tetapi bagi package manager yang sudah ada ini tampaknya akan menjadi masalah riset besar
    • Sebagian besar jumlah baris kemungkinan berasal dari crate Windows API yang dihasilkan. Crate-crate ini terkenal sangat besar

  • Rust bukan lagi bahasa baru yang menarik, melainkan sedang memasuki tahap menuju adopsi luas. Melambatnya pengembangan fitur itu wajar dan sehat
    Saat ini, kesalahan desain jauh lebih merugikan daripada laju yang lambat. Rust menarik bukan karena fitur-fitur keren, melainkan karena ia merupakan kelas baru bahasa yang memory-safe, tanpa garbage collection, dan siap produksi. Diadopsi secara nyata di tempat-tempat penting lebih menarik daripada membuat bahasanya lebih bagus, dan itu lebih mudah terjadi jika ada kepercayaan bahwa bahasa ini dikelola dengan hati-hati

    • JavaScript juga bisa dibilang berada pada tahap hidup yang mirip, tetapi selama 10 tahun terakhir ada banyak fitur baru yang hebat ditambahkan
      Spread operator, generator function, async, arrow function, leftpad, Date baru, dan daftar fitur pentingnya tidak ada habisnya. JS jauh lebih tua dan jauh lebih banyak digunakan daripada Rust, serta memiliki banyak implementasi produksi, sehingga semua fitur baru harus diimplementasikan secara konsisten. Ada masa stagnasi sekitar ES5, tetapi perbedaannya tampaknya karena komite standar ECMAScript akhirnya sadar
    • Ada/SPARK sudah ada sejak lama, jadi saya ragu apakah ini benar-benar kelas bahasa baru. SPARK membawa keamanan lebih jauh lagi, sampai mencakup verifikasi formal

  • Karena Rustacean begitu terobsesi menulis ulang semuanya dalam Rust, saya sungguh mengira tulisan tentang menulis ulang Rust akan menjadi lelucon satir meta

    • Itu sudah terjadi pada zaman prasejarah. Awalnya Rust ditulis dalam OCaml, tetapi akhirnya ditulis ulang dalam Rust
    • Saya penulis artikel aslinya. Referensi yang saya maksud di judul memang itu
    • Mereka ingin membuat kalian, atau kita, menulis ulang semuanya dalam Rust. Bukan mereka sendiri
    • Orang-orang di bidang bahasa pemrograman juga menyukai bootstrapping. Menulis Rust dengan Rust tidaklah sekonyol itu

  • Agak aneh bahwa tulisan ini lebih dulu mengeluhkan pengambilan keputusan yang lambat, lalu menyebutkan deretan fitur yang alasan belum distabilkannya tidak begitu berkaitan dengan pengambilan keputusan
    Misalnya, coroutine terhambat karena ada kasus-kasus sudut yang sulit diselesaikan dengan benar. Bukan berarti di dalam compiler sudah ada implementasi lengkap yang “tinggal dinyalakan”, melainkan implementasi yang belum selesai: bekerja dalam banyak kasus, tetapi belum bisa diaktifkan di versi stabil. Function trait juga sudah diputuskan secara eksplisit untuk tidak distabilkan dalam bentuknya sekarang karena berbagai alasan teknis dan interaksi dengan fitur-fitur mendatang. Kalau bisa kembali ke masa lalu, memang ada bagian yang mungkin akan dirancang berbeda, tetapi sebagian besar terkait keputusan pada masa awal Rust ketika tim dan sumber dayanya jauh lebih kecil. Bisa saja ada gagasan bahwa karena sekarang kita bisa membuat pilihan yang lebih baik, sebaiknya dibuat pemutusan ala Rust 2.0, tetapi karena bencana transisi Python 2 ke 3 begitu besar, banyak orang merasa lebih baik menerima sisi-sisi kasarnya. Kalau melihat buletin mingguan Rust, persetujuan RFC dan keputusan stabilisasi diproses setiap minggu. Memang ada kasus yang memakan waktu terlalu lama, tetapi masalah kekurangan orang, koordinasi, dan waktu sering kali lebih sulit diselesaikan daripada masalah teknis

  • Tulisan ini juga perlu dibaca bersama jawaban Reddit dari Josh Triplett. Salah satu contoh utama dalam tulisan itu, Mutex, memang keliru
    https://old.reddit.com/r/rust/comments/1fpomvp/rewriting_rus...
    Koreksi: komentar yang sama juga ada di sini
    https://news.ycombinator.com/item?id=41655268

  • Hal pertama yang saya rasakan saat belajar Rust adalah bahwa hampir semua fitur yang bisa dibayangkan sepertinya sudah ada di dalamnya
    Bukan berarti tim Rust tidak pernah menolak sesuatu, tetapi orang-orang tetap menginginkan lebih banyak fitur. Sebagian memang beralasan, tetapi sebagian lain tampak seperti fitur yang hanya akan dipakai 2% developer dan hanya dipahami 1% developer, namun dianggap harus dimasukkan ke bahasa. Bahasa yang kompleks tidak perlu menjadi lebih kompleks lagi. Zig lebih sederhana dan mungkin lebih cepat, dan drama komunitasnya juga jauh lebih sedikit. Saya berharap Zig mendapat lebih banyak pendanaan

    • Anda mungkin terkejut mengetahui bahwa cukup banyak fitur yang diusulkan orang secara acak lalu ditolak oleh komunitas Rust
      Rust tidak berusaha memasukkan semua fitur yang mungkin. Namun kalau tidak jelas masalah apa yang diselesaikan oleh sesuatu seperti GAT atau TAIT, memang bisa terasa begitu. Zig mungkin bahasa modern yang bagus, tetapi kalau tujuannya adalah memory safety, itu bukan pilihan
    • Saya penulis tulisan aslinya. Menurut saya, anggaran kompleksitas Rust banyak dipakai di tempat yang salah
      Misalnya, interaksi antara Pin dan future menambahkan kompleksitas yang tidak masuk akal ke bahasa, dan menurut saya sebagian di antaranya tidak perlu. Saya berharap ada bahasa mirip Rust yang sama sekali tidak memiliki Pin. Borrow checker juga sepertinya bisa disederhanakan baik dari sisi sintaks maupun implementasi, meski saya belum memikirkannya secara konkret. Sekarang mungkin sulit diubah kecuali dengan mem-fork bahasa, tetapi Rust tidak akan menjadi bahasa terakhir yang memakai borrow checker. Saya berharap generasi berikutnya punya banyak ruang untuk perbaikan tanpa harus membuat bahasa yang lebih besar
    • Pendanaan yang lebih besar bisa menarik tipe orang yang buruk. Keburukan mereka dan potensi kerusakannya kadang baru terlihat ketika sudah terlambat
    • Saya penasaran drama komunitas Rust yang dimaksud itu apa
      Saya memang melihat drama terkait Rust, tetapi biasanya datang dari pihak yang menolak penggunaan atau adopsi Rust. Misalnya keributan Rust for Linux baru-baru ini. Sepertinya itu bukan hal yang umum terjadi di dalam komunitas, meski mungkin ada yang saya lewatkan. Zig bagus, tetapi belum siap untuk produksi
    • Kuburan fitur yang terkubur di nightly sebenarnya cukup besar. Fitur penting seperti specialization pun stuck di sana selamanya

  • Penulis komentar yang ditautkan, setelah menganalisis secara luas primitive sinkronisasi di berbagai bahasa, menulis ulang primitive sinkronisasi Rust seperti Mutex dan RwLock agar langsung memakai primitive OS tingkat bawah di tiap sistem operasi utama
    Dengan memakai hal seperti futex di Linux, ia membuatnya lebih cepat, lebih kecil, dan secara keseluruhan lebih baik; dalam prosesnya, ia praktis juga menulis buku tentang pemrograman paralel Rust. Buku itu juga berguna untuk pemrograman paralel di luar Rust
    https://www.oreilly.com/library/view/rust-atomics-and/978109...
    Ia juga bukan sekadar bermain-main di ranah coroutine selama 7 tahun. Ia menambahkan fungsi async, trait yang bisa memuat fungsi async, dan berbagai fitur yang diperlukan untuk menstandarkan AsyncWrite dan AsyncRead; di nightly juga ada implementasi generator. Masih didiskusikan apakah akan menanggung kompleksitas coroutine yang sepenuhnya umum, atau berhenti di generator. Beberapa fitur seperti AsyncIterator memang lambat, tetapi ada banyak pekerjaan aktif. Selalu menarik melihat satu pihak mengatakan bahasa ini terlalu lambat, sementara pihak lain mengeluh terlalu cepat
    Trait fungsi dan effect system juga baru-baru ini mengalami eksplorasi desain besar, dan mereka ingin menemukan solusi agar fungsi tidak perlu ditulis berkali-kali untuk setiap kombinasi async, try, dan const. Sandboxing crate berbahaya bukan masalah tingkat bahasa; itu memerlukan kombinasi verifier dan sandbox runtime, dan komponen WebAssembly tampak lebih berpotensi. Namun ada banyak minat pada capability waktu kompilasi seperti pilihan allocator atau runtime async, serta asumsi platform 64-bit; sandboxing proc macro diinginkan bukan untuk mencegah niat jahat, melainkan untuk caching yang akurat
    Struct yang mereferensikan dirinya sendiri bukan masalah sintaks, melainkan masalah yang sangat sulit ditangani borrow checker. Borrow parsial sudah didukung dalam capture closure, tetapi kuncinya adalah bagaimana mempertahankan versioning semantik yang stabil saat diekspos dalam API publik. Opsi seperti “borrow group” bernama tampaknya menjanjikan. Di sisi comptime juga sedang ada pekerjaan ke berbagai arah, dan RFC untuk memperkuat macro_rules juga baru-baru ini ditulis. impl untuk Range sudah berjalan, dikaitkan dengan perubahan yang tidak kompatibel melalui edition. Penggabungan if let dengan AND logis memiliki fitur unstable dan sudah dekat untuk distabilkan. Ada juga beberapa proposal untuk memperbaiki sintaks akses field pointer, tetapi apakah memperluas permukaan bahasa memberi manfaat atau justru kerugian masih menjadi pertanyaan terbuka. Berkat edition Rust, banyak hal bisa diubah jika desainnya cukup meyakinkan. 700 fitur unstable adalah masalah nyata, sehingga diperlukan pekerjaan besar untuk merapikan fitur-fitur yang kecil kemungkinannya bisa distabilkan

    • Pengembangan paket dasar setingkat standard library memang seharusnya dilakukan seperti ini. Bahasa-bahasa yang dipakai sekarang akan terus digunakan selama puluhan tahun ke depan, dan membuat keputusan yang lambat tetapi baik sekarang akan menghemat jauh lebih banyak waktu nantinya
    • Ada banyak diskusi tentang sandboxing proc macro dan build script
      Macro yang lebih deklaratif, pendelegasian logika crate -sys ke shared library, serta cfg(version) / cfg(accessible) akan sangat mengurangi kebutuhan implementasi oleh pengguna, tetapi runtime tetap tersisa. Semakin dipikirkan, ACL milik cackle tampak seperti cara yang baik dan dapat diperluas untuk melacak pekerjaan di seluruh proc macro, build script, dan kode runtime, serta mengaudit penggunaan dependency tree. Saya dengar cargo-redpen juga sedang berkembang sebagai alat audit pemanggilan, tetapi saya membayangkan sesuatu di level yang lebih tinggi seperti cackle
      https://github.com/cackle-rs/cackle
    • Saya penulis artikel aslinya. Senang bisa mendengar sudut pandang orang dalam secara mendetail
      Saya paham orang mengeluh bahwa Rust sudah menjadi bahasa besar dan mereka tidak ingin ia makin besar, tetapi mempertahankan implementasi async yang setengah matang saat ini tidak membuat bahasa menjadi lebih kecil atau lebih sederhana. Itu hanya membuat bahasanya menjadi lebih buruk. Untuk borrow parsial juga, akan bagus jika bisa bekerja setidaknya di dalam crate yang sama, meski bukan sebagai API publik. Ini masalah yang terus-menerus ditemui dalam pemrograman nyata. Saya juga bertanya-tanya mengapa sandboxing crate berbahaya mustahil di tingkat bahasa. Jika sebuah fungsi tidak memiliki kode pihak ketiga unsafe dalam call tree dan juga tidak melakukan system call, maka ia hanya bisa menangani argumen yang sudah diberikan, variabel lokal, dan global dalam scope. Jika dinding ini bisa diperkuat dan dipakai sebagai batas keamanan, tampaknya risiko supply chain dependency bisa dikurangi secara besar

  • Misi Rust sejak awal adalah hal sulit: memadukan performa, keamanan, dan daya ekspresi; ketika Mozilla keluar, Rust kehilangan mode pendiri, dan sebagian besar tim inti aslinya juga sudah pergi, jadi tidak mengejutkan jika progresnya melambat
    Secara pribadi, saya menganggap itu lebih baik daripada mengambil jalan yang salah

  • Jika Rust ditulis ulang, rasanya arahnya akan lebih ke mengurangi fitur daripada menambah fitur
    Seperti QBE terhadap LLVM, kira-kira menyediakan 70% Rust dengan 10% kode. Mungkin bisa jika macro dan sebagian fitur yang jarang dipakai dihilangkan
    https://c9x.me/compile/

    • Bukan bermaksud meremehkan QBE, tetapi tujuan awal QBE adalah menyediakan 90% performa dengan 10% kode, lalu kemudian berubah menjadi 70%
      Baik untuk Rust maupun yang lain, sulit mengetahui seberapa mungkin itu sebelum benar-benar dicoba