Apa arti Ubuntu menggunakan Rust?

• Adopsi Rust oleh Ubuntu menunjukkan bahwa Rust dalam siklus adopsi teknologi sedang bergeser dari early adopter, melewati chasm, menuju tahap arus utama
• Canonical mengadopsi Rust sebagai bahasa default untuk perangkat lunak fondasi baru, menggantikan penggunaan C, C++, dan sebagian Python, serta berinvestasi dalam pengembangan utilitas yang aman terhadap memori baik dari sisi pendanaan maupun reputasi
• Karena pengguna Early Majority menginginkan "standar industri" dan kompatibilitas dengan workflow yang ada, penggantian utilitas secara drop-in menjadi strategi kunci untuk melewati chasm
• Isu perluasan standard library Rust kembali mengemuka, dan konsep "Rust Platform" yang ditolak pada 2016 kini dinilai ulang sebagai sesuatu yang justru bisa cocok bagi Early Majority
• Struktur yang menghubungkan perluasan adopsi dengan investasi, serta inklusivitas berbasis empati (empathy) dalam komunitas open source, sangat penting untuk tahap pertumbuhan Rust berikutnya

---

'Melewati chasm' bagi Rust berbeda di tiap domain

• Apakah Rust sudah melewati chasm dalam Technology Adoption Life Cycle berbeda-beda tergantung domainnya
• Di internal Amazon, Rust sudah sangat mapan untuk membangun data plane skala besar atau agen yang sadar sumber daya, tetapi untuk pengembangan umum masih ada persepsi bahwa Rust terlalu berlebihan
• Di ranah Safety Critical Software, sudah ada kisah sukses, tetapi sebagian besar industri masih berada dalam mode "wait and see"

Pentingnya "reference customer"

• Kunci untuk melewati chasm adalah mendapatkan reference customers
• Early adopter membeli "change agent", tetapi Early Majority menginginkan peningkatan produktivitas operasi yang ada dan berusaha meminimalkan diskontinuitas
• Melihat organisasi serupa berhasil adalah faktor paling meyakinkan dalam mengadopsi teknologi baru
• Keberhasilan Rust di tim S3 memang meyakinkan bagi tim layanan berskala besar, tetapi kurang langsung meyakinkan bagi tim layanan CRUD

Strategi adopsi Rust Ubuntu (Canonical)

• Dalam Rust Nation, VP of Engineering Canonical, Jon Seager, menyampaikan keynote "Rust Adoption At Scale with Ubuntu"
• Canonical sebelumnya membatasi bahasa pengembangan internalnya pada Python, C/C++, dan Go, tetapi belakangan menambahkan Rust dan mengadopsinya sebagai bahasa default untuk pekerjaan fondasi baru
• Mirip dengan keynote Lars Bergstrom tentang adopsi Rust di Google, pendekatan ini menggabungkan visi dan pragmatisme
  • Inilah karakteristik yang tepat untuk beralih dari early adopter ke Early Majority

Investasi pada utilitas yang aman terhadap memori

• Jon Seager menyebut Ubuntu perlu mendukung pembangunan utilitas berbasis memory safety sebagai bentuk "pay it forward"
• Canonical mendanai pengembangan sudo-rs dan ntpd-rs milik Trifecta Tech Foundation, serta pekerjaan coreutils dari uutils
• Ubuntu lebih dulu mencoba dan memvalidasi hal-hal baru agar distro lain kemudian bisa ikut merasakan manfaatnya
• Utilitas drop-in yang bisa masuk ke workflow lama apa adanya sesuai dengan kebutuhan Early Majority untuk meminimalkan diskontinuitas

Kebutuhan adopter baru: perluasan standard library

• Dalam sebuah jamuan makan, Jon Seager mengatakan bahwa kebijakan standard library kecil milik Rust perlu ditinjau ulang
• Ini adalah permintaan yang telah berulang selama bertahun-tahun; bukan sekadar menyediakan standard library besar, tetapi membayangkan alternatif dalam bentuk proyek bernama "Battery Packs"
• Rust Platform yang diusulkan pada 2016 (gagasan untuk mengakui crate tertentu sebagai standard library yang diperluas) dulu ditolak oleh early adopter, tetapi kini dinilai ulang sebagai sesuatu yang mungkin cocok bagi Early Majority
  • Saat itu pandangan yang dominan adalah bahwa menambahkan dependensi ke Cargo.toml saja sudah cukup

Perlunya perubahan untuk pertumbuhan

• Untuk beralih dari early adopter ke Early Majority, diperlukan pesan bahwa Rust bukan "state-of-the-art" melainkan "industry standard"
• Rust berhasil membangun pengenalan di industri, dan kini harus menjadi pilihan terbaik berdasarkan "apa Rust sebenarnya", bukan "apa yang mungkin bisa menjadi Rust"
  • Keduanya kadang bisa saling tegang
• Untuk memasarkan kepada kaum pragmatis, dibutuhkan kesabaran, pemahaman atas isu industri terkait, dan kehadiran di konferensi industri

Struktur yang menghubungkan adopsi dengan investasi

• Perluasan adopsi Rust disertai dengan peningkatan permintaan terhadap proyek dan ekosistem Rust
• Bagi organisasi open source seperti Canonical, yang lebih penting daripada $$ adalah membangun hubungan antarlembaga dan kontribusi
  • Pengembang Rust for Linux awalnya dibantu maintainer Rust, tetapi secara bertahap mulai memperbaiki bug sendiri, sementara maintainer beralih ke peran mentor
• Tren yang menarik, pendanaan sering kali datang dari perusahaan yang sedang mempertimbangkan adopsi Rust, bukan dari perusahaan yang sudah mengadopsinya
  • Early adopter di dalam organisasi mendorong adopsi internal dan mengalokasikan anggaran untuk membangun fitur "table stakes"
• Menurut Alexandru Radovici dari Rust Foundation Silver Member Directory, banyak perusahaan perangkat lunak safety-critical punya dana untuk menutup gap Rust, tetapi tidak tahu bagaimana cara menggunakannya

Peran open source dan pentingnya empati

• Open source adalah platform yang sangat baik untuk melewati chasm, tetapi klik-klik kecil (cliques) dan "tradisi lisan (oral traditions)" bisa menjadi hambatan masuk
• Penggunaan istilah yang salah dapat membuat ide ditolak, dan satu respons yang kasar dapat membuat kontributor baru pergi
• Hal yang paling dibutuhkan Rust untuk tahap pertumbuhan berikutnya adalah Empathy in Open Source
• Kuncinya adalah mendatangi tempat di mana Rust bisa membantu orang, lalu mendukung dan memberdayakan mereka

[GN⁺]

Komentar Hacker News

• Fakta bahwa Ubuntu menggunakan userland dengan lisensi non-GPL berarti hal itu bisa membuka lebih banyak ruang untuk TiVoization dalam ekosistem Linux
  Jika digabung dengan arah yang dibawa Amutable dari kubu systemd, bisa saja muncul distro Linux tertutup yang tidak dapat dimodifikasi pengguna
  Dari sudut pandang perusahaan, lingkungan tertutup dengan verifikasi tanda tangan penuh bisa terlihat menarik. Membayangkan dunia di mana bahkan “ls” atau “cd” menjadi closed source terasa agak apokaliptik

  • Bukan berarti util-linux atau BSD akan hilang. Kalau tidak suka Ubuntu, ya jangan pakai. Debian dulu jauh lebih stabil
  • Sebenarnya ada alasan kenapa dulu disebut GNU/Linux. Android/Linux juga bukan userland GPL, dan kebanyakan pesaing embedded juga bukan GPL. Pada akhirnya, Linux hanyalah kernel
  • Secara historis mungkin saya naif, tapi saya tidak merasa perubahan seperti ini pasti buruk. Saya tetap lebih suka utilitas open source, tetapi saya rasa tidak masalah jika ada alternatif tertutup yang mematuhi spesifikasi. Perusahaan juga bisa jadi akan menyalurkan lebih banyak dana ke proyek open source dengan cara itu
  • Jujur saja, Ubuntu terasa seperti Apple-nya Linux yang lebih menang lewat marketing daripada kualitas. Keluarga Debian dipakai karena biaya pemeliharaannya rendah, dan secara pribadi saya merasa Fedora atau OpenSUSE adalah masa depan
  • Kalau perubahan seperti ini membuat 95% pengguna Linux memakai OS yang sama, mungkin itu juga tidak terlalu buruk

• Jurang (chasm) yang sebenarnya yang harus dilampaui Rust adalah dukungan dynamic linking dengan ABI yang aman
  Rust perlu bisa menjamin keamanan meski satu library diubah, dan mencapai stabilitas ABI setingkat C agar adopsi Rust di kubu C/C++ menjadi memungkinkan

  • Rust sudah bisa berkomunikasi lewat ABI C. Ia menyediakan kemampuan dynamic linking di tingkat yang setara dengan C++
  • Stabilitas ABI di C++ justru adalah penyebab utama terhambatnya evolusi bahasa. Layout kelas STL tidak bisa diubah, dan template yang diimplementasikan di header juga sulit dioptimalkan belakangan. Rust seharusnya tidak mendukung “stable ABI” seperti itu
  • Efisiensi Rust bergantung pada monomorfisasi saat kompilasi. Untuk membuat ABI, perlu mempertimbangkan spesialisasi saat link time. Ini bukan sekadar memindahkan code generation ke linker, tetapi juga harus menangani “shape” parameter fungsi dengan sangat hati-hati
  • Dynamic linking juga membantu mengurangi waktu kompilasi saat debug build. Library yang tidak berubah tidak perlu dibangun ulang, dan overhead runtime-nya sangat kecil
  • Agak disayangkan komunitas Rust lebih menyukai MIT daripada GPL. GPL berpihak pada pengguna, MIT berpihak pada perusahaan. Saya merasa gerakan “Rewrite-it-in-Rust” terlalu fokus pada penyebaran bahasa, bukan perlindungan pengguna

• Masalah yang lebih besar daripada adopsi Rust oleh Ubuntu adalah bahwa mereka masih menangani build penting dengan skrip curl|bash
  Itu terlihat jelas di snapcraft.yaml milik firefox-snap

  • Kalau mendengar “curl|bash”, biasanya yang terbayang adalah perubahan konfigurasi acak atau modifikasi .bashrc, tetapi kali ini hanya sebatas menjalankan skrip instalasi toolchain statis. Cara ala 90-an, tapi relatif aman
  • Ada banyak distro yang versi Rust-nya terlalu tua. Rust di Debian atau Ubuntu LTS adalah versi yang sudah ketinggalan zaman, jadi tampaknya mereka memang tidak suka static linking
  • Bahkan kalau menjalankan sesuatu lewat curl, itu tetap oke asal verifikasi hash dilakukan dengan benar

• Fakta bahwa proyek Rust Coreutils memakai lisensi MIT terasa mengganjal
  Filsafat FSF memang sering dikritik, tetapi GPL melindungi open source. Kalau Canonical mengubah Ubuntu secara keseluruhan menjadi MIT, entah apa yang akan terjadi

  • Dulu GPL sangat kuat, tetapi sekarang berkat sistem pencucian hak cipta otomatis, banyak kode yang pada akhirnya berubah menjadi MIT/BSD atau kode komersial. FSF pun tidak punya solusi
  • Perdebatan lisensi tidak akan pernah selesai. GPL membatasi adopsi, sedangkan MIT lebih fleksibel. Pada akhirnya semua tergantung apa tujuannya — apakah Anda ingin OSS yang bisa dipakai semua orang, atau ingin mencegah perusahaan mengambil keuntungan tanpa berkontribusi
  • Saya penasaran, setelah Coreutils menjadi MIT, “kejahatan” konkret apa yang sebenarnya jadi mungkin dilakukan

• Karena rust-coreutils, instalasi CUDA Toolkit tidak bisa dilakukan. Isu terkait ada di forum NVIDIA

  • Thread yang ditautkan tampaknya soal masalah gzip. Sepertinya bukan karena dd
  • Terus terang, rust-coreutils tidak punya alasan untuk ada. Hal pertama yang harus dilakukan setelah memasang Ubuntu adalah menginstal ulang coreutils asli dan sudo

• Konsep “Crossing the chasm” menarik. Selain kasus coreutils di Ubuntu, ada banyak jurang lain yang sedang coba dilampaui Rust
  Ada Rust for Linux atau Rust untuk industri otomotif, tetapi sejauh ini tampaknya masih berhenti di level driver

  • Rust sedang meluas ke banyak arah. pyo3(pengganti modul Python), Dioxus(web framework mirip React), Ferrocine(compiler untuk otomotif), dan lain-lain adalah contoh yang representatif. Proyek DARPA TRACTOR juga mempercepat adopsi Rust
  • Dokumen Project Goals milik Rust (tautan) menunjukkan ke arah mana komunitas menginvestasikan fokus utamanya
  • Rust sendiri hebat, tetapi masalahnya adalah sebagian komunitas hanya “menulis ulang ke Rust” software lama yang sudah stabil sambil membajak brand. Ubuntu juga tampaknya terjebak dalam virtue signaling seperti itu

• Logika bahwa standard library bisa diubah nanti itu berbahaya. Pengguna menginginkan sistem yang stabil dan berkualitas tinggi, bukan “jurang”

  • Dalam kasus Rust, standard library bukan “diubah” melainkan mudah ditambahkan. Ada rilis baru setiap 6 minggu, dan tiap kali lebih dari 10 fitur baru ditambahkan. Sudah ada ratusan fitur di stdlib

• Ketidakmatangan ekosistem Rust adalah faktor yang menghambat adopsi. Banyak crate masih berada di versi sebelum 1.0 atau sekadar wrapper C yang sederhana. Untuk kriptografi cukup bagus, tetapi hal seperti SAML sulit ditemukan

  • Versi pre-1.0 tidak perlu terlalu dikhawatirkan. Karena ada budaya mematuhi SemVer secara ketat, banyak proyek menunda deklarasi 1.0. Crate seperti libc, yang sangat terikat dengan API, juga sulit dinaikkan versinya. Secara pribadi saya merujuk ke daftar terkurasi seperti blessed.rs
  • gettext juga baru mencapai 1.0 setelah 30 tahun
  • Modul cryptography di Python mewajibkan Rust toolchain sehingga tidak bisa diinstal di lingkungan Termux. Fakta bahwa dependensi Rust membuat bahkan proyek Python jadi lebih berat terasa merepotkan

• Ada gerakan untuk “menerjemahkan” kode C++ ke Rust secara vibe-translate sambil mengganti lisensinya. Misalnya, sudo-rs justru punya rekam jejak keamanan yang lebih buruk daripada versi C

  • Propaganda seputar Rust, AI, dan keamanan terasa berlebihan. Awalnya saya menyukai Rust, tetapi kontroversi lisensi MIT dan promosi yang berlebihan makin terasa melelahkan

• Standard library yang besar di .NET benar-benar nyaman. Sebagian besar pekerjaan bisa dilakukan dengan cara standar, dan kalau ada implementasi aneh, mayoritas orang akan mendorong standarisasi

  • Saya rasa stdlib kecil di Rust adalah sebuah kesalahan. stdlib adalah satu-satunya dependensi yang selalu ada, jadi meski tidak sempurna, seharusnya ia menyediakan lebih banyak alat
  • Tetapi dari sudut pandang system programmer, stdlib besar justru menjadi masalah. .NET berbasis GC jadi tidak terlalu peduli, tetapi Rust atau C++ harus bisa berjalan juga di lingkungan bare-metal. stdlib yang besar menjadi beban di lingkungan dengan batas memori ketat(<64K)
    std/core milik Rust sendiri sudah terlalu besar sehingga di mikrokontroler perlu trik seperti weak symbol.
    stdlib kecil lebih menguntungkan untuk menjaga stabilitas API dan mengurangi beban pemeliharaan. C++ sudah banyak menderita karena masalah ini, jadi Rust harus berhati-hati