Seperti yang diminta, berikut adalah saran saya untuk mengembangkan Rust pada 2019 dan seterusnya.

Saya harus mengatakan bahwa saya berbicara hanya untuk diri saya sendiri, dan saya bahkan bukan peserta yang sangat aktif dalam proyek ini. Selain itu, proposal ini berhubungan dengan sebagian besar proyek. Rust adalah kasus khusus, tetapi dialah yang sekarang mengarah ke beberapa pemikiran.

Saya juga harus mencatat bahwa saya umumnya puas dengan perkembangan Rust, dan proposal ini dibuat hanya demi mempertahankan kemakmuran lebih lanjut, untuk menghindari beberapa masalah yang sekarang saya amati dari luar.

TL; DR: Penting untuk mengetahui masalah dan merencanakan mekanisme eksplisit untuk membatasi pertumbuhan dua hal:

1. Artefak teknis umum wajib, terutama definisi suatu bahasa.
2. Beban pada orang-orang yang terlibat dalam diskusi artefak ini.

Secara khusus, saya ingin menarik perhatian pada ketidakmungkinan dan tidak diinginkannya pertumbuhan tanpa batas di kedua arah. Ada batasan alami. Seperti dalam semua sistem alami yang telah mencapai batas pertumbuhan, lebih baik untuk mempersiapkan acara ini dan melakukannya secara terkontrol dan terencana.

Harap dicatat bahwa saya tidak menulis tentang batas pertumbuhan banyak area lainnya. Misalnya, indeks paket, ukuran situs, atau bahkan komunitas pengguna. Tidak jelas ancaman seperti apa yang ditimbulkan oleh Rust, jadi kami hanya berbicara tentang dua masalah khusus di atas.

Faktor pembatas dan penerbangan

Setiap sistem alami memiliki batas pertumbuhan. Itulah mengapa Semesta bukan (misalnya) amuba tunggal yang mengembang dengan kecepatan cahaya. Sistem tumbuh (dan seringkali kecepatan ekspansi juga tumbuh!) Sampai bertemu dengan faktor pembatas, dan kemudian secara bertahap pertumbuhan melambat hingga keseluruhan ukuran sistem mencapai dataran tinggi. Pola pertumbuhan khas dalam kasus ini kira-kira terlihat seperti sigmoid atau "kurva berbentuk S", yang secara bertahap mendekati beberapa asimtot. Setidaknya jika faktor pembatas terjadi secara bertahap dan terkendali.



Ketika suatu sistem menemukan batas dengan cara yang tidak terkontrol atau tiba - tiba , sebuah fenomena dapat terjadi yang lebih mirip pelarian target atau bahkan pengembalian: batas itu masih ada, tetapi efeknya lebih terasa seperti keruntuhan atau krisis. Kurva S naik ke puncak, diikuti oleh keruntuhan. Saya ingin menghindari ini.

Contoh Kontrol yang Baik

Proyek Rust memiliki beberapa bentuk kontrol proses yang pada dasarnya membatasi laju perubahan dan / atau pertumbuhan. Saya pikir langkah-langkah ini sangat masuk akal: sebagian berkat mereka, proyek ini masih berhasil. Dengan analogi dengan mereka, saya ingin merumuskan rekomendasi berikut. Bentuk manajemen saat ini:

• Antrian Bors melewatkan perubahan kebenaran untuk program.
• Kawah melewatkan rilis kebenaran ekosistem.
• Rilis yang direncanakan lebih disukai untuk dirilis tepat waktu, bahkan jika fitur yang direncanakan tidak siap. Keputusan diambil tepat waktu, dan segala sesuatu yang tidak siap terputus.

Selain itu, struktur sosial penting telah dibuat dalam proyek untuk membatasi jumlah peserta proyek.

• Kode Etik . Tidak semua orang ingat, tetapi dia tidak hanya mendalilkan keadilan sosial dan sebagainya. Ini juga menetapkan batasan pada rasio sinyal-ke-suara dalam percakapan, eksploitasi perhatian dan waktu orang lain, dan mendorong kompromi (lagi pula, tidak semua solusi memberikan jumlah nol).
• Proses RFC . Aturan tentang bentuk, isi, waktu, rekrutmen peserta, bentuk wacana yang diizinkan dan yang diharapkan saat membahas perubahan signifikan.
• Model manajemen . Delineasi tanggung jawab, delegasi hirarkis, jika perlu, peran dan harapan peserta dan sebagainya.

Semua ini, pada dasarnya, adalah pengakuan bahwa dengan tidak adanya masalah kontrol dan krisis dapat terjadi: setidaknya kekacauan dan disfungsi sampai batas tertentu. Jika memungkinkan, kontrol otomatis dan sepenuhnya tidak memihak (untuk meminimalkan niat buruk dan penilaian subyektif, godaan untuk mengambil jalan pintas, dll.) Jika subjektivitas tidak dapat dihindari, setidaknya aturan dan proses secara jelas dirumuskan secara tertulis, di tempat yang terdokumentasi dengan baik, tempat-tempat terkenal. .

Area masalah

Mari kita kembali ke dua bidang masalah di mana proyek saat ini tidak memiliki mekanisme atau kebijakan yang memadai untuk mengendalikan Rust, yang membawa risiko kemungkinan disfungsi atau bahkan krisis. Dalam kedua kasus, tidak sepenuhnya jelas seberapa jauh proyek ini sekarang dari krisis seperti itu. Tetapi bagaimanapun juga, lebih baik bertindak di muka daripada terlambat.

1. Bahasa itu sendiri . Definisi itu. Ini (tidak seperti banyak bagian dari proyek) adalah artefak teknis umum wajib . Setiap orang tertarik padanya, dan setiap perubahan berpotensi memengaruhi setiap orang. Selain itu, setiap orang harus mempelajari dan memahami bagian esensialnya: tidak mungkin mengabaikan bagian yang tidak menarik. Bahkan apa yang ingin Anda abaikan ada dalam konteks umum: dokumentasi dan materi pelatihan, contoh uji dan bahan pengujian, komponen penyusun internal, model formal, basis kode, beban perawatan umum, dll.
   
   Di sini pertumbuhan bahasa sebagai artefak dibatasi oleh setidaknya faktor-faktor berikut:
   
   
   • Kesempatan bagi pemula untuk belajar bahasa.
   • Kemampuan pengguna rata-rata untuk merasa percaya diri, beradaptasi dengan basis kode orang lain.
   • Kemampuan seorang ahli atau pengelola untuk mengetahui semua (atau sebagian besar) perubahan.
   • Rasio biaya dan manfaat dari setiap perubahan baru dalam hal pekerjaan baru dan berkelanjutan. Jumlah orang atau kasus penggunaan yang mendapat manfaat dari itu. Biaya adalah kombinasi dalam banyak dimensi desain dan ukuran bahasa. Mereka hampir selalu meningkat.
   
   Jika Anda tidak mematuhi batasan ini, Anda dapat menghadapi risiko yang sangat serius:
   
   
   • Perubahan bahasa yang tidak masuk akal, hingga ketidakmampuan untuk mempertahankan jaminan keamanan kritis.
   • Reputasi kompleksitas yang berlebihan, kehilangan pengguna. Risiko menjadi C ++ atau Haskell berikutnya.
   • Fungsi kualitas buruk dengan definisi, tes, dokumentasi tidak lengkap.
   • Fitur yang kurang dimanfaatkan yang membutuhkan upaya yang diperlukan di tempat lain.
   • Menghancurkan ke dalam dialek, program terisolasi, pengurangan nilai.
2. Beban pada orang yang mengerjakan bahasa. Beberapa bagian dari proyek dapat didelegasikan, didistribusikan di antara semua pengembang yang tersedia. Ini bukan artefak teknis yang umum. Hingga taraf tertentu, banyak orang (dan lebih banyak dan lebih) harus berpartisipasi dalam hampir semua perubahan. Ini berarti banyak tekanan pada semua orang dalam kelompok ini: mereka harus mengikuti semua diskusi, dan jumlah perubahan dan jumlah peserta dalam diskusi meningkat.
   
   Beberapa batasan pada pertumbuhan beban ini untuk peserta proyek:
   
   
   • Jumlah jam per hari.
   • Jumlah jam yang dibayarkan per hari.
   • Tanggung jawab dan kepentingan di luar proyek.
   • Cadangan energi mental untuk memahami apa yang terjadi.
   • Percaya diri pada pendapat semua orang yang terlibat dalam percakapan.
   • Cadangan energi psikologis dan emosional untuk membaca dan berdiskusi.
   • Anggapan niat baik semua orang yang terlibat dalam percakapan.
   
   Risiko melampaui batas-batas ini juga berpotensi sangat serius:
   
   
   • Keputusan buruk dibuat karena kelelahan atau kelelahan.
   • Tumbuh Ketimpangan: Hanya peserta yang paling istimewa, terjangkau, energik, bergaji baik, atau yang terorganisasi dengan baik yang dapat melacak semuanya.
   • Mempersempit wacana: dari pertimbangan yang cermat hingga “memenangkan perselisihan”.
   • Orang-orang main-main, terbakar, berperilaku buruk, meninggalkan proyek.
   • Kekecewaan, tuduhan ketidakjujuran, kebencian, pemikiran konspirasi, percabangan.
   
   Saya ingin menekankan bahwa batasan dan risiko yang dijelaskan sama sekali tidak spesifik untuk orang tertentu atau bahkan proyek Rust secara keseluruhan. Untuk tingkat yang bervariasi, mereka dapat ditemukan di mana saja. Cukup mengganti pengelola saat ini (misalnya) dengan yang Anda sukai tidak akan benar-benar menyelesaikan masalah: pembatasan akan tetap ada. Satu-satunya solusi adalah manajemen yang bijaksana dalam tabrakan dengan batas. Kendalikan.

Opsi kontrol yang mungkin

Ini adalah bagian yang sulit, di mana saya akan mencoba untuk menghindari bahasa yang jelas. Pada akhirnya, penting untuk mengendalikan kehendak bebas sendiri, dan tidak dipaksakan dari luar. Saya pikir bahwa peserta proyek harus berhenti, berefleksi, secara kolektif mempertimbangkan dan membangun beberapa kontrol. Karena itu, saya hanya akan menawarkan beberapa opsi yang mungkin, tidak terlalu terstruktur, tetapi dalam semangat Natal yang meriah: sebagai sekelompok hadiah yang berpotensi menarik untuk dibuka, dilihat dan diputuskan, pergi atau menukar sesuatu yang lebih menarik.

1. Ruang yang ditentukan secara negatif . Ambil proses membahas fungsi dan konsep dari rencana untuk pengembangan bahasa di masa depan. Izinkan (atau dorong) RFC yang mengatakan "Karat tidak akan pernah memiliki X" untuk beberapa nilai X. Jadi kami mendapatkan satu kali putaran untuk diskusi yang adil dan pertimbangan keberatan terhadap perubahan jangka panjang ("tidak pernah" adalah waktu yang cukup lama!). Maka diskusi ini akan berakhir selamanya. Itu tidak akan menjadi sumber abadi konflik berkepanjangan. Beberapa contoh di mana ruang negatif didefinisikan:
   
   
   • secara permanen menghapus kategori ekspresif tertentu dari sistem tipe (misalnya, tipe dependen, HKT, dll.);
   • dari sintaks (mis. kunci parameter, argumen posisi atau bernama);
   • dari serangkaian tampilan elemen (misalnya, jenis posting anonim);
   • dari seperangkat kewajiban ke output ke middle-end (misalnya, sintesis konstanta, argumen implisit).
   
   Tetapkan beberapa batasan sulit: untuk menghindari benda-benda ini, serta orang-orang yang menetapkan tujuan "melakukan segalanya dengan benar."
2. Biaya pengembangan perlu dinyatakan secara eksplisit. Mengambil halaman dari daftar perubahan ke WebAssembly, jelaskan bahwa pada tahap awal, RFC seperti itu akan memerlukan investasi yang sesuai dalam implementasi, formalisasi, revisi dokumentasi, revisi materi pelatihan, tes penulisan, pemeliharaan, dll. Jika biaya tidak dapat ditanggung, pada tahap ini menunda perubahan "hingga sponsor ditemukan."
3. Tetapkan tujuan untuk kecepatan belajar dan volume materi . Cobalah untuk bekerja dengan arah yang berlawanan: mulai dari jumlah waktu dan jumlah halaman yang diperlukan untuk mempelajari bahasa atau menjadi ahli di dalamnya - dan kemudian hapus semua yang melampaui kerangka ini. Jika "mempelajari Karat dalam 21 hari" tidak berhasil, cari interval yang tepat. Tiga bulan? Enam? Tahun? Pikirkan bahasa-bahasa yang pembelajarannya “pasti memakan waktu terlalu banyak” dan pilih angka yang lebih rendah. Apakah manual 1000 halaman oke? 500? 300?
4. Tetapkan batas otomatis lainnya: jumlah baris kode dalam kompiler, total waktu muat, dolar per hari untuk instance AWS, jumlah aturan dalam tata bahasa, dalam sistem tipe, persentase cakupan pengujian, persentase dokumen yang dapat ditandai sebagai "tidak lengkap", dll. Jadilah kreatif, cari tahu hal-hal relevan yang dapat diukur, dan kemudian terapkan mekanisme untuk membatasi mereka.
5. Batas waktu pribadi : berapa banyak kira-kira jam (atau waktu yang dibayar) yang dapat dicurahkan seseorang untuk suatu proyek tanpa kelelahan atau kelelahan, termasuk peserta dengan hak minimal. Tetapkan pembatasan serupa pada grup, rilis individual, dan rencana kerja terkait. Kemudian hapus atau tunda semua yang tidak sesuai dengan batas.
6. Izinkan moderator untuk menetapkan batas pada frekuensi posting atau mengatur periode hening dalam diskusi tertentu. Terkadang dari luar sepertinya pembahasannya terlalu panas. Untuk mengurangi konflik, lebih mudah untuk menetapkan batas bersama daripada menerapkan sanksi kepada masing-masing peserta.
7. Seperti halnya moderator: buat tim lintas proyek tambahan yang terlibat dalam penganggaran dan audit tingkat muatan di tim lain . Ini bisa efektif: tim audit akan membantu orang mengatakan tidak ketika diperlukan, dan tidak bertahan, seperti yang dilakukan sebagian besar anggota tim, terlalu banyak menyetujui.

Ini hanya beberapa ide dalam arah umum pembatasan pertumbuhan. Saya yakin Anda dapat menemukan cara yang lebih realistis untuk mengendalikan pembatasan ukuran bahasa dan muatan pribadi. Selama bertahun-tahun, komunitas Rust telah terbukti kreatif, berpikiran, dan kritis terhadap diri sendiri. Anda harus dipuji untuk ini. Saya harap artikel ini akan diterima dalam semangat kritik membangun yang sama.

Selamat Tahun Baru dan semoga sukses!