干貨分享|Rust“巨坑”？真相來了！
發(fā)布時(shí)間：2023-08-17 14:01:31
Rust 是一門極具爭(zhēng)議性的語言。有許多創(chuàng)業(yè)公司的開發(fā)者甚至創(chuàng)始人都點(diǎn)名表示：Rust 是巨坑！簡(jiǎn)直浪費(fèi)時(shí)間。再比如，其他語言中的“粗糙編碼”的編程方式在 Rust 中也很難實(shí)現(xiàn)；庫(kù)和文檔也不夠成熟，學(xué)習(xí)起來相當(dāng)費(fèi)勁，諸如此類。
但總的來說，在強(qiáng)調(diào)“安全性比開發(fā)生產(chǎn)力更重要”的今天，Rust 從來沒有失去成為一種未來語言的資格。雖然正視缺點(diǎn)很重要，但有些草率的批評(píng)也許未必是真相，或者說是不準(zhǔn)確的。
今天將為大家展示“不偏不倚”的 Rust 的真實(shí)特性。
1、并非所有開發(fā)都是系統(tǒng)編程
2、語言復(fù)雜性
漫長(zhǎng)的編譯時(shí)間往往會(huì)壓垮每一位程序員。用運(yùn)行速度較慢但編譯速度較快的編程語言編寫的代碼，通常更有機(jī)會(huì)運(yùn)行得更快，因?yàn)槌绦騿T有更多時(shí)間來優(yōu)化代碼。
Rust 在通用性難題中故意選擇了緩慢的編譯器。這不一定是世界末日（因?yàn)橛纱水a(chǎn)生的運(yùn)行時(shí)性能增益是真實(shí)的），但這確實(shí)意味著在較大的項(xiàng)目中，開發(fā)者將不得不努力爭(zhēng)取合理的構(gòu)建時(shí)間。
rustc 實(shí)現(xiàn)了生產(chǎn)編譯器中可能最先進(jìn)的增量編譯算法，但這感覺有點(diǎn)像與語言編譯模型作斗爭(zhēng)。
與 C++ 不同，Rust 構(gòu)建并沒有笨拙地并行化，并行度受到依賴圖中關(guān)鍵路徑長(zhǎng)度的限制。如果有 40 個(gè)以上的內(nèi)核進(jìn)行編譯，則會(huì)顯示此信息。
Rust 還缺乏類似 pimpl 的功能，這意味著更改 crate 需要重新編譯（不僅僅是重新鏈接）其所有反向依賴項(xiàng)。
4、相對(duì)年輕的語言
Rust 只有 8 年的歷史，相較而言，Rust 還算一門年輕的語言。創(chuàng)建這個(gè)新語言的目的是為了解決一個(gè)頑疾：軟件的演進(jìn)速度大大低于硬件的演進(jìn)，軟件在語言級(jí)別上無法真正利用多核計(jì)算帶來的性能提升。
根據(jù)林迪效應(yīng)，相信“C++ 將在未來十年內(nèi)存在”的人要遠(yuǎn)多于對(duì)“Rust 將在十年內(nèi)存在”的人。同樣地，如果你編寫的軟件可以使用數(shù)十年，在選擇新技術(shù)之前，往往會(huì)再三考慮與之相關(guān)的風(fēng)險(xiǎn)。
但慎重考慮并不代表放棄新技術(shù)。一個(gè)過去的案例就是，在 90 年代為銀行軟件選擇 Java 而不是 Cobol 事實(shí)證明是正確的選擇）。
Rust 目前只有一種完整的實(shí)現(xiàn)——rustc 編譯器。另一個(gè)最佳替代實(shí)現(xiàn)，mrustc，有意省略了許多靜態(tài)安全檢查。rustc 目前僅支持一種生產(chǎn)就緒后端 - LLVM。因此，它對(duì) CPU 架構(gòu)的支持范圍比 C 語言更窄，后者具有 GCC 實(shí)現(xiàn)以及許多特定于供應(yīng)商的專有編譯器。
最后，Rust 缺乏官方規(guī)范。參考文檔正在開發(fā)中，尚未記錄實(shí)現(xiàn)的所有細(xì)節(jié)。
5、可替代性
在系統(tǒng)編程領(lǐng)域，除了 Rust 之外，還有其他一些語言，主要是 C、C++ 和 Ada。
現(xiàn)代 C++ 提供了提高安全性的工具和指南，甚至有人為 C++提出了類似 Rust 的生命周期機(jī)制。但與 Rust 不同，使用這些工具并不能保證沒有內(nèi)存安全問題。但是，如果你已經(jīng)維護(hù)了大量 C++ 代碼，那么檢查以下最佳實(shí)踐和使用清理程序是否有助于解決安全問題是有意義的。這很困難，但顯然比用另一種語言重寫它要容易。
如果你使用 C，你可以使用形式化方法來證明不存在未定義的行為，否則你只能詳盡地測(cè)試一切。如果不使用動(dòng)態(tài)內(nèi)存（切勿調(diào)用 free），Ada 是內(nèi)存安全的。
Rust 偏偏是成本/安全曲線上的一個(gè)有趣的權(quán)衡點(diǎn)，但肯定不是唯一的不可替代的點(diǎn)。
6、工具
Rust 工具是值得點(diǎn)贊叫好的?；€工具、編譯器和構(gòu)建系統(tǒng)（cargo）通常被認(rèn)為是一流的。
但是，例如，一些與運(yùn)行時(shí)相關(guān)的工具（尤其是堆分析）目前還不存在——如果沒有運(yùn)行時(shí)工具，就很難分析程序的運(yùn)行時(shí)。此外，雖然 IDE 支持不錯(cuò)，但它還遠(yuǎn)未達(dá)到 Java 級(jí)別的可靠性。如今，在 Rust 中不可能自動(dòng)復(fù)雜地重構(gòu)數(shù)百萬行程序。
7、性能
“使用 LLVM”并不是解決所有性能問題的通用方法。雖然我不知道 C++ 和 Rust 的大規(guī)模性能基準(zhǔn)，但不難列出一些 Rust 不如 C++ 的性能問題。
最大的一個(gè)可能，是 Rust 的移動(dòng)語義是基于值的（機(jī)器代碼級(jí)別的 memcpy）。相比之下，C++ 語義使用特殊引用（機(jī)器代碼級(jí)別的指針），可以在其中處理數(shù)據(jù)。
理論上，編譯器應(yīng)該能夠看穿復(fù)制鏈，但實(shí)際上卻常常做不到。要知道， 一個(gè)相關(guān)的問題是不放置新的——Rust 有時(shí)需要從堆棧復(fù)制字節(jié)，而 C++ 可以就地構(gòu)造東西對(duì)象。
有趣的是，為了使其盡可能高效而不穩(wěn)定，Rust 的默認(rèn) ABI 有時(shí)比 C 更糟糕。
8、不安全（Unsafe）的定義
（1）可解釋（非不安全（non-unsafe）的代碼不會(huì)導(dǎo)致未定義的行為） （2）@模塊化（可以單獨(dú)檢查不同的不安全塊）
其次，據(jù)業(yè)內(nèi)開發(fā)者的觀察結(jié)果是，unsafe 實(shí)際上并不是模塊化的。足夠強(qiáng)大的不安全塊實(shí)際上可以擴(kuò)展語言。兩個(gè)這樣的擴(kuò)展，單獨(dú)使用時(shí)可能沒問題，但如果一起使用，可能會(huì)導(dǎo)致未定義的行為、觀察到的等效性和不安全的代碼。
