Integrasi Rust di Linux telah memiliki tingkat penerimaan yang tinggi oleh komunitas dan pengembang
Salah satu masalah utama yang muncul dalam pengembangan Kernel Linux untuk waktu yang lama, adalah ide untuk menemukan kandidat yang sempurna untuk mengubah bahasa pemrograman "C" untuk yang lebih modern dan hingga saat ini dengan kedatangan Rust, ide ini tidak berhenti diletakkan di atas meja.
Dengan pratinjau pertama Rust di Linux 6.1, Saya menghidupkan kembali semangat sebagian besar pengembang dari Kernel dan Jonathan Corbet menunjukkan bahwa "masih tidak akan cukup Rust di kernel untuk melakukan sesuatu yang menarik", dimasukkannya bahasa ini telah menghidupkan kembali perdebatan tentang perlunya membuang bahasa C yang mendukung Rust dalam hal dari pemrograman sistem. Pertanyaannya membagi komunitas pengembang.
asahi linya mengambil tugas mengembangkan driver graphics processing unit (GPU) untuk Mac M1 di Rust.
Tentang perbandingan Anda antara bahasa Rust dan C menyebutkan bahwa:
"Sama sekali tidak ada kemungkinan Anda tidak harus berurusan dengan manajemen akses bersamaan, upaya pasca-rilis untuk mengakses area memori, dan segala macam masalah lain jika Anda menulis ini di C. Semua masalah konkurensi hilang dengan Rust! Memori dibebaskan saat dibutuhkan! Setelah Anda mempelajari cara membuat Rust berfungsi untuk Anda, menurut saya ini akan memandu Anda untuk menulis kode yang layak, bahkan di luar janji keamanan bahasa tersebut. Ini benar-benar ajaib! »
"Ada banyak perdebatan tentang apakah Rust berguna atau tidak di kernel... menurut pengalaman saya, ini jauh lebih berguna daripada yang pernah saya bayangkan!" ", tambahnya.
Komentar Anda seperti berulang dari kompilasi alasan teknis yang mungkin membenarkan membuang bahasa C demi Rust. Faktanya, 15,9% dari 2288 kerentanan yang telah memengaruhi kernel Linux dalam 20 tahun (angka dari kamus Common Vulnerabilities and Exposure (CVE)) terkait dengan kelemahan dalam bahasa C, masalah yang terkait dengan pengelolaan memori: buffer overflows , alokasi tidak dibebaskan, akses ke area memori yang tidak valid atau dibebaskan, dll.
Selain itu, pengelola utama kernel Linux sudah familiar dengan bahasa C, yang usianya sudah dianggap di usia ke-3. Generasi baru pengelola yang kelompok usianya berada di tiga puluhan sedang meningkat, dan dengan demikian kesulitan menemukan pengelola untuk kernel Linux cenderung meningkat jika pengembangannya dilanjutkan dalam bahasa C. Alasan mengapa Linus Torvalds membuka pintu untuk kernel pengembangan di Rust.
Pada pertanyaan tentang kemungkinan membuang bahasa C, pencipta bahasa C mencantumkan sejumlah alasan mengapa inisiatif cenderung gagal yang menuju ke arah ini:
Rantai Alat Bahasa VS
Bahasa C bukan hanya bahasa itu sendiri, tetapi juga semua alat pengembangan yang dikembangkan untuk bahasa ini.
Apakah Anda ingin melakukan analisis statis terhadap kode sumber Anda? – Ada banyak orang yang mengerjakan ini untuk C. Alat untuk mendeteksi kebocoran memori, balapan data, dan kesalahan lainnya? Ada banyak, bahkan jika bahasa Anda dilengkapi dengan lebih baik.
Jika Anda ingin menargetkan platform yang kurang dikenal, kemungkinan Anda menggunakan status C. C sebagai lingua franca komputasi saat ini membuatnya layak untuk alat tulis, dan banyak alat ditulis.
Jika ada yang memiliki rantai alat yang berfungsi:
mengapa mengambil risiko mengubah bahasa? "C yang lebih baik" harus menghasilkan banyak produktivitas tambahan untuk memotivasi waktu yang dihabiskan untuk menyiapkan rantai alat baru. Apakah ini mungkin masih harus dilihat.
Ketidakpastian bahasa baru
Sebelum suatu bahasa mencapai kedewasaan, kemungkinan akan bermasalah. dan dimodifikasi secara signifikan untuk mengatasi masalah semantik bahasa. Dan apakah bahasanya konsisten dengan iklan? Itu dapat menawarkan sesuatu seperti "waktu kompilasi yang luar biasa" atau "lebih cepat dari C", tetapi tujuan ini menjadi sulit dicapai ketika bahasa menambahkan
Dan para pengelolanya? Tentu, Anda dapat menggunakan bahasa sumber terbuka, tetapi saya ragu banyak perusahaan akan tertarik menggunakan bahasa yang mungkin terpaksa mereka gunakan nanti. Bertaruh pada bahasa baru adalah risiko besar.
Fakta bahwa bahasanya mungkin tidak cukup baik
Apakah bahasa tersebut membahas poin rasa sakit yang sebenarnya dari C?
Ternyata itu Orang tidak selalu setuju dengan kelemahan C. Alokasi memori, penanganan array dan string seringkali rumit, tetapi dengan perpustakaan yang tepat dan strategi memori yang baik, hal itu dapat diminimalkan.
Bukankah bahasa mengatasi masalah yang tidak terlalu dipedulikan oleh pengguna tingkat lanjut? Jika demikian, nilai aktualnya bisa jauh lebih kecil dari yang diharapkan.
Dan lebih buruk lagi, bagaimana jika bahasa tersebut menghilangkan fitur penting yang ada di C? Fitur yang diandalkan oleh pemrogram C tingkat lanjut? Risiko ini meningkat jika perancang bahasa belum banyak menggunakan C, tetapi berasal dari C++, Java, dll.
Kurangnya pengembang berpengalaman untuk bahasa baru
Bahasa baru secara alami akan memiliki kumpulan pengembang berpengalaman yang jauh lebih kecil. Untuk perusahaan menengah atau besar mana pun, ini adalah masalah besar. Semakin banyak pengembang yang tersedia untuk perusahaan, semakin baik.
Juga, jika perusahaan memiliki pengalaman merekrut pengembang C, mereka tidak tahu cara merekrut untuk bahasa baru ini.
Terakhir, jika Anda tertarik untuk mengetahuinya lebih lanjut, Anda dapat berkonsultasi dengan detailnya di tautan berikut.