Karat untuk Gophers

Baca artikel asal di packagemain.tech

Adakah anda patut Berkarat, atau patutkah anda Pergi? Bahasa mana yang lebih baik, dan adakah soalan itu masuk akal? Mari bercakap tentang Go versus Rust pada tahun 2024, dengan tetamu istimewa kami, John Arundel. John ialah pengarang For the Love of Go, Cloud Native DevOps dengan Kubernetes, dan banyak buku lain. Dia juga mengajar Go dan Rust, jadi ia akan menarik untuk mendengar perspektifnya. Inilah temu bualnya!

John, kami nampaknya semakin banyak mendengar tentang Rust hari ini. Bolehkah anda memberi kami pengenalan segera? Untuk apa Rust, dan mengapa ia wujud?

Sudah tentu, itu mudah. Karat ialah bahasa untuk mengawal lif.

Adakah anda bergurau?

Tidak sama sekali. Graydon Hoare, pengasas Rust, kecewa apabila lif di bangunannya terus rosak akibat masalah perisian. Dia fikir "Sudah tentu kita boleh melakukan lebih baik daripada ini!" Dan selebihnya adalah sejarah.

Kami tidak boleh menghalang semua pepijat, tetapi kami sekurang-kurangnya boleh menggunakan bahasa pengaturcaraan yang menghapuskan beberapa kategori utama pepijat, seperti limpahan penimbal, perlumbaan data dan isu "penggunaan selepas percuma". Jadi sejak awal lagi, tumpuan Rust tertumpu pada membina perisian yang boleh dipercayai, mengautomasikan banyak pemeriksaan keselamatan yang dilakukan oleh pengaturcara yang baik, dan membantu mengesan kesilapan sebelum ia mencapai pengeluaran.

Bunyinya seperti idea yang bagus, tetapi saya mendapat tanggapan bahawa Rust adalah bahasa yang sukar untuk dipelajari—terutamanya berbanding dengan Go. Adakah itu adil, dan jika ya, mengapa?

Go dan Rust kedua-duanya mencuba, dalam cara yang berbeza, untuk menyelesaikan masalah yang sama: sukar untuk menulis perisian pada skala dalam bahasa tradisional seperti C dan C++, kerana pengaturcara harus sangat berpengalaman dan berpengetahuan untuk mengelakkan kesilapan. Malah pakar boleh tergelincir dari semasa ke semasa, dan memerlukan masa yang lama untuk melatih pengaturcara supaya menjadi pakar.

Go menangani masalah ini dengan memudahkan bahasa secara radikal: berbanding dengan sesuatu seperti C++, ia mempunyai sintaks yang lebih sedikit untuk dipelajari. Jadi pengaturcara boleh menghabiskan masa mereka belajar menulis program dengan baik, dan bukannya menguasai bahasa yang besar dan kompleks. Go kurus, tetapi berkesan.

Untuk menggunakan analogi, lebih mudah untuk belajar memandu traktor daripada menerbangkan kapal angkasa. Traktor mungkin mesin yang sederhana dan pragmatik, tetapi ia melakukan tugasnya dengan sempurna, dan ia sebenarnya merupakan pilihan yang lebih baik daripada kapal angkasa untuk banyak tugas: membajak sawah, contohnya.

Saya suka analogi anda. Saya rasa Rust adalah kapal angkasa?

Ya, Rust adalah besar, rumit dan berkuasa, menggabungkan banyak idea terbaik daripada bahasa imperatif tradisional seperti C dengan konsep pengaturcaraan berfungsi yang dipinjam daripada bahasa seperti Haskell dan Lisp.

Terdapat lebih banyak yang perlu dipelajari dalam Rust daripada yang terdapat dalam Go, tetapi kemudian ia melakukan lebih banyak lagi! Jika anda ingin terbang ke Marikh, kapal angkasa adalah pilihan yang lebih baik daripada traktor. Sudah tentu, ia mengambil masa lebih lama untuk melatih seorang angkasawan berbanding pemandu traktor.

Go mempunyai pengumpulan sampah terbina dalam, yang bagus untuk kesederhanaan. Bagaimanakah pengurusan memori berfungsi dalam Rust, dan adakah ini satu cabaran besar untuk dipelajari?

Ya, kutipan sampah bermakna anda tidak perlu risau tentang memperuntukkan dan membebaskan memori sendiri, seperti yang anda lakukan dalam bahasa seperti C++. Itu menjadikan pengaturcaraan lebih mudah dan menghapuskan semua jenis pepijat yang berkaitan dengan memori. Sebaliknya, anda memerlukan masa jalan yang agak kompleks dan kutipan sampah menjejaskan prestasi.

Karat mengambil pendekatan yang berbeza. Ia menuntut semula memori secara automatik, tetapi tanpa perlu menjeda atur cara. Ia boleh melakukan ini dengan menjejaki semua rujukan kepada sekeping data tertentu yang wujud. Apabila tiada bahagian program boleh merujuk kepada data lagi, Rust tahu bahawa sedikit ingatan boleh dikitar semula dengan selamat terus.

Ya, saya pernah mendengar Rust mempunyai tumpuan yang kuat pada pemilikan dan peminjaman. Bagaimanakah konsep ini dibandingkan dengan menggunakan penunjuk dalam Go, dan apakah beberapa cara yang baik untuk membungkus kepala saya?

Nah, saya ada berita baik—jika anda sudah biasa dengan penunjuk dalam Go, maka rujukan dalam Rust pada asasnya berfungsi dengan cara yang sama, hanya lebih selamat. Jika anda mencipta rujukan boleh ubah kepada pembolehubah, ia berfungsi sama seperti penuding Go: anda boleh menghantarnya ke fungsi atau menyimpannya di suatu tempat.

Tetapi, tidak seperti dalam Go, selagi rujukan boleh ubah itu wujud, ia mempunyai akses eksklusif kepada data: tiada orang lain boleh mengubah suainya, malah membacanya. Dalam istilah Go, ia seperti mempunyai kunci mutex automatik. Dan apabila fungsi tidak perlu mengubah suai data, ia sebaliknya boleh meminjam rujukan dikongsi, yang dibaca sahaja, dan banyak daripadanya boleh wujud serentak.

Karat juga menjejaki data asal: apabila ia keluar dari skop, sebarang rujukan kepadanya tidak lagi sah. Jadi pengkompil boleh mengesan pelbagai jenis pepijat penunjuk berjuntai di mana anda cuba menggunakan rujukan kepada nilai yang tidak wujud lagi. Ini mengakibatkan tingkah laku yang tidak ditentukan, yang merupakan cara yang baik untuk mengatakan bahawa sesuatu yang mengerikan akan berlaku, dan sebahagian daripada cadangan nilai Rust ialah "tiada tingkah laku yang tidak ditentukan—sekali-kali".

Dalam Rust, maka, kita perlu memikirkan cara untuk menulis atur cara kita supaya rujukan kepada data sentiasa sah dan hanya satu rujukan boleh ubah wujud pada satu-satu masa. Itu memerlukan sedikit masa untuk membiasakan diri (pengaturcara Rust memanggilnya "melawan pemeriksa pinjaman"), tetapi program yang dihasilkan lebih dipercayai dan lebih berkemungkinan betul.

Sebagai contoh, semua pengaturcara Go sudah biasa dengan perlumbaan data, di mana dua atau lebih gorout cuba mengakses beberapa data yang dikongsi pada masa yang sama, dengan hasil yang tidak dapat diramalkan: paling baik, program akan ranap, dan paling teruk, ia akan diteruskan dengan data yang rosak atau tidak sah.

Dalam Rust, program seperti ini tidak akan disusun! Peraturan pemilikan dan rujukan bermakna dua rujukan boleh ubah kepada perkara yang sama tidak boleh wujud serentak. Anda hanya perlu menyelesaikan masalah dengan cara yang berbeza.

Itu membawa kita dengan kemas kepada keselarasan. Saya suka ciri konkurensi Go dengan saluran dan goroutin. Bagaimanakah Rust mengendalikan konkurensi, dan adakah terdapat persamaan yang boleh saya manfaatkan daripada pengalaman Go saya?

Ya, goroutin dan saluran sangat bagus: abstraksi tugas super ringan yang sangat murah berbanding dengan multithreading tradisional. Sebaliknya, Go hanya memberi kita asas asas: terpulang kepada kita untuk memastikan kita menggunakannya dengan selamat, mengelakkan perlumbaan data atau kebuntuan. Dan itu mungkin sukar dilakukan!

Karat tidak mempunyai goroutin, tetapi ia mempunyai tugas async, yang hampir sama dengan goroutin, hanya dengan jaminan keselamatan Karat biasa. Terdapat juga beberapa rangka kerja pihak ketiga yang sangat baik seperti Tokio dan Rayon yang hanya boleh mengambil sekumpulan data dan secara automatik memikirkan cara paling berkesan untuk menguraikannya secara selari.

Jadi, walaupun program serentak akan sentiasa sukar untuk ditulis dengan baik, jika anda boleh melakukannya dalam Go, anda akan mendapati kemahiran tersebut dipindahkan dengan baik kepada Rust juga.

Saya suka belajar dengan melakukan. Adakah terdapat sebarang latihan atau projek praktikal yang baik yang anda cadangkan untuk pengaturcara Go yang bermula dengan Rust, seperti Tour of Go, sebagai contoh?

Rustlings ialah tempat yang bagus untuk bermula: ia merupakan satu set latihan saiz gigitan interaktif yang membimbing anda melalui semua asas bahasa. Jika anda ingin mendapatkan maklum balas daripada manusia hidup yang sebenar, lihat trek Rust on Exercism. Terdapat juga Rust by Example, yang merupakan sumber hebat untuk coretan contoh yang berfungsi.

Nampaknya anda peminat kedua-dua bahasa. Mana yang anda lebih suka, dan adakah anda mengesyorkan bahawa seseorang yang sudah mengenali Go juga harus mencuba mempelajari Rust?

Ya, Go dan Rust masing-masing menarik bahagian otak saya yang berbeza. Saya suka kesederhanaan radikal dan pragmatisme Go: ia melakukan banyak perkara dengan sangat sedikit, dan menyelesaikan kebanyakan masalah dengan baik.

Karat, sebaliknya, mengisi jurang dengan kemas di mana Go bukanlah pilihan yang ideal: kernel, perisian tegar, peranti terbenam dan aplikasi kritikal keselamatan seperti peranti perubatan, industri, aeroangkasa dan sebagainya.

Dan lif, sudah tentu.

Sememangnya! Jadi saya suka aspek Rust itu, dan ia juga bahasa yang sangat menyeronokkan dan ekspresif. Saya rasa ia amat berbaloi untuk sesiapa sahaja bermain dengan Rust, dan bertahan dengannya cukup lama untuk mengatasi ketidakbiasaan awal sintaks dan perjuangan dengan penyemak pinjaman.

Walaupun anda memutuskan bahawa Rust bukan untuk anda, anda akan mempelajari beberapa cara baharu yang menarik untuk memikirkan masalah dan ia juga membantu anda memahami lebih lanjut tentang pertukaran berbeza yang Go buat.

Dari sudut kerjaya, Go dan Rust akan menjadi kemahiran yang sangat berharga untuk masa hadapan. Saya rasa tidak lama lagi, bukannya "Pergi lawan Karat", kita akan bercakap tentang "Pergi dan Karat lawan segala-galanya."

John, terima kasih kerana menjadi tetamu kami dan memberi kami perspektif anda tentang Go and Rust. Di manakah orang boleh mengetahui lebih lanjut tentang anda—contohnya, jika mereka berminat dengan buku atau kursus latihan anda?

Suka hati saya! Sila kunjungi tapak web saya di bitfieldconsulting.com jika anda ingin mengetahui lebih lanjut atau hubungi—saya akan berbesar hati untuk bersembang.

Atas ialah kandungan terperinci Karat untuk Gophers. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!