我用 Rust 程式設計的這兩年

摘要:近年來,Rust 被越來越多大廠投入使用,如微軟的 VS Code、Visual Studio 等工具已提供對 Rust 的良好支持,Google 也宣佈 Android 支持 Rust 語言來開發作業系統,Linux 核心也有意引入 Rust 程式碼等等。那麼,對於個人開發者來說,用 Rust 程式設計又有什麼不同呢?

連結:https://n-eq.github.io/blog/2022/11/01/rust-fiddling-2-years

聲明:本文為 CSDN 翻譯,未經允許禁止轉載。

作者 | Nabil Elqatib

譯者 | 彎月

時間過得真快,距離我第一次接觸 Rust,已經過去差不多兩年了。我想通過本文反思一下這段旅程中一些令我印象深刻的事情和一些經驗教訓。

下面是我第一次提交 Rust 程式碼的截圖。雖然時間可以追溯到 2021 年 1 月,但實際上在這之前,我已經在這段程式碼上折騰好幾個星期了。

第一次接觸 Rust

第一次接觸 Rust

2020 年 12 月,我找到了一份新工作,但在這之前我早就對 Rust 有所耳聞。以前,我從事的是嵌入式開發,在我看來 Rust 是一門很強大的現代語言,最終有可能發展成為堪比 C/C++ 的主流語言。我感覺不認真學習 Rust 就有可能錯過一個新時代。

初印象

初印象

首先申明,我沒有正式地學習過 Rust,只是通過實踐、閱讀程式碼和文件自學。回想起來,我認為這不是一個很好的學習方法,我堅信花一些時間來學習官方提供的資料,快速理解語言及其設計理念和生態系統,這些都是必須的。接下來,才能用 Rust 編寫一些嚴肅的項目。

Rust 的學習曲線很陡峭

Rust 的學習曲線很陡峭

我記得,Rust 宣稱其最大優勢是強類型語言,能夠在編譯期間跟蹤對象的生命週期以及所有引用的變數範圍,因此能夠防止記憶體安全錯誤。

思路看似非常簡單,但實際上使用靜態變數和 RC 處理多個 crate 簡直就是一場噩夢。對我來說,理解這個新概念極其有難度,而繞過該概念的最容易的方法就是不斷克隆變數,但這不僅是錯誤的做法,尤其是在處理大型資料結構時,而且還會在你終於理解該概念之後帶來很多麻煩。

幸運的是,編譯器提供了很多提示和指向文件的連接,我必須說這真的很有幫助。

編譯器不是正規的驗證工具

編譯器不是正規的驗證工具

這是一個很常見的誤解,最近我與一位同事探討 Rust,他認為 Rust 程序不可能會因為運行時越界而崩潰。然而不幸的是,Rust 編譯器不是可以醫治百病的靈丹妙藥,有些程序雖然編譯成功,但運行時還是會出問題。下面,舉一個最常見的 Rust 資料結構的示例:

let mut v = vec![];v.push(0);v.clear();let _ = v[0]; // panics

下面這段程式碼更狡猾:

let mut v = Vec::new();#[cfg(target_os = "windows")]v.push("a");let _ = v[0]; // panics

在編譯時檢測越界訪問需要對程式碼進行深度分析,會極大地降低編譯速度(在我看來 Rust 的編譯已經很慢了)。

Rust可能無法預測

Rust可能無法預測

我們團隊最近發現了一個問題,我們的某個 crate(依賴)在生產環境下會在特定條件時崩潰。長話短說,如果使用了特定版本的 reqwest,且使用了其 rustls-tls-native-roots 特性,那麼在系統證書不正確時就會崩潰。

我對此很驚訝,因為照此看來使用依賴是有風險的。即使現在的絕大部分 crate 都是開源的,人們也不太可能審查所有程式碼,更不用說評判使用時的風險了。絕大部分 crate 的文件都很差,這也印證了這一觀點。如果能有一個像樹一樣分析項目依賴的工具,並給出所有容易崩潰的 crate 的鳥瞰圖就好了。

解決該問題的方法是過載 Rust 的 panic_handler, 但這種方法只有在 #![no_std] 的項目中才能使用。

程序的可執行檔案可能非常大

程序的可執行檔案可能非常大

說起嵌入式的 no_std 非常有意思。我並沒有在記憶體受限環境和低端設備上編寫 Rust 程序的經歷。儘管現在這不是個問題,但我還是要說,Rust 的可執行檔案太大了。

我讀過一些這方面的文章,其中一些給出了很好的觀點。但我認為,Rust 想在記憶體受限環境下取代 C,還有很長一段路要走。在 #![no_std] 的世界中,我相信 Rust 仍然需要找到一種方法,來提供多種不依賴於默認的格式化函數的崩潰處理庫,因為默認的格式化函數非常消耗記憶體。

Rust 工具的可互換性非常好

Rust 工具的可互換性非常好

這一點也讓我很驚訝,但這是一個好訊息。

我從事的某個項目中包含大約 90 萬行 C 語言程式碼,負責與 Rust 接口。有了 Rust,實現這一點並沒有太大困難,甚至十分簡單,而且許許多多 crate 和示 例也能證實這一點。通過 FFI 機制,編寫其他語言程式碼的 Rust 綁定非常容易。我不敢說其他語言,但至少對 C 家族(C/C++/Objective-C)的支持非常好。

這並不是說完全不用做任何工作,因為你仍然需要寫一些程式碼,將各個部分「粘」在一起,但這是必須付出的代價,而且我覺得這代價非常低。此外,我很高興看到 Rust 堅持了自己的理念,要求使用者將低級程式碼定義為「不安全」(基本上,所有的 FFI 函數事實上都是不安全的,因為 Rust 對其他語言編寫的程式碼沒有任何控制權)。

Rust 很強大

Rust 很強大

我想用正面的評價來結束這篇文章。Rust 是一個非常豐富的語言,它在系統程式設計方面擁有巨大的潛力。限制所有權和借出機制能保證資料訪問的安全性和高效率。更現代的語法和設計,使其更容易理解,而且也更容易使用多種程式語言模式和最新的正規化。更不用說,Rust 的並行支持非常好,進程可以很容易地並行運行,不需要考慮競爭條件以及類似的問題。

結束語

結束語

我很喜歡使用 Rust。如果我有機會選擇一門開發語言,那一定會毫不猶豫地選擇 Rust。我看到了 Rust 的巨大潛力,希望它在未來能在嵌入式系統中大放異彩。最近出現的 Rust Linux 核心模組讓我們看到了光明的前景。

☞宮敏把自由軟體和 Linux 帶回中國

☞周鴻禕:360 基本不觸碰使用者資料;蘋果與亞馬遜被指控合謀推高 iPhone 等產品價格|極客頭條

☞印度開發者增速超中國,GitHub 年度報告發布

相關文章

Rust vs Go,到底該怎麼選?

Rust vs Go,到底該怎麼選?

【CSDN 編者按】擁有 40 多年程式設計經驗的知名 Go 開發者與作家 John Arundel 在其個人部落格分享了《Rust vs ...

載入速度慢?Android Cocos 最佳化實戰

載入速度慢?Android Cocos 最佳化實戰

針對 Cocos 遊戲存在載入速度慢的問題,技術團隊進行了最佳化。不僅僅提升了使用者體驗的提升,而且最佳化了項目結構,還為未來遊戲-原生跨環...