作者丨lochsh

譯者丨馬可薇

策劃丨王文婧

在詳細介紹 Rust 之前，我們先舉一個例子。想象你是一個為新房子搭建煤氣管道的工人，你的老板想要你去地下室把煤氣管連到街上的主煤氣管道里，然而你下樓時卻發(fā)現(xiàn)有個小問題，這個房子并沒有地下室。所以，現(xiàn)在你要做什么呢？什么都不做，還是異想天開地妄圖通過把煤氣主管道連到隔壁辦公室的空調(diào)進氣口來解決問題？不管怎么說，當你向老板匯報任務完成時，你或許會在煤氣爆炸的土灰中以刑事疏忽罪起訴。

這就是在某些編程語言中會發(fā)生的事。在 C 里是數(shù)組，C++ 里可能是向量，當程序試圖尋找第 -1 個元素時，什么都有可能發(fā)生：或許是每次搜索的結果都不同，讓你意識不到這里存在問題。這種被稱作是未定義的行為，它發(fā)生的可能性并不能完全被杜絕，因為底層的硬件操作從本質上來說并不安全，這些操作在其他的編程語言里可能會被編譯器警告，但是 C/C++ 并不會。

在無法保證內(nèi)存安全的情況下，未定義行為極有可能發(fā)生。漏洞 HeartBleed，一個著名的 SSL 安全漏洞，就是因為缺少內(nèi)存安全防護；Stagefright，同樣出名的安卓漏洞，是因為 C++ 里整數(shù)溢出造成的未定義行為。

內(nèi)存安全不止用來提防漏洞，它對應用程序的正確運行和可靠性同樣至關重要?？煽啃缘闹匾栽谟谒梢员ＷC程序不會突然崩潰。至于準確性，作者有一個曾經(jīng)在火箭飛行模擬軟件公司工作的朋友，他們發(fā)現(xiàn)傳遞相同的初始化數(shù)據(jù)，但是使用不同的文件名會導致不同的結果，這是因為有些未初始化的內(nèi)存被讀取，因此模擬器就不同文件名的原因而使用了垃圾數(shù)值做基礎，可以說他們的這個項目毫無用處。

Python 和 Java 使用自動垃圾回收來避免內(nèi)存錯誤，例如：

• 釋放重引用（Use-After-Free）：申請已經(jīng)被釋放的內(nèi)存。

• 多次釋放（double free）：對同一片內(nèi)存區(qū)域釋放兩次，導致未定義行為。

• 內(nèi)存泄漏：內(nèi)存沒有被回收，導致系統(tǒng)可用的內(nèi)存減少。

自動垃圾收集會作為 JVM 或者 Python 解釋器的一部分運行，在程序運行時不斷地尋找不再使用的模塊，釋放他們相對應的內(nèi)存或者資源。但是這么做的代價很大，垃圾回收不僅速度緩慢還會占用大量內(nèi)存，而你也永遠不會知道下一秒你的程序會不會暫停運行來回收垃圾。

Python 和 Java 的內(nèi)存安全犧牲了運行速度。C/C++ 的運行速度則是犧牲了內(nèi)存的安全性。

這種讓人無法掌控的垃圾回收讓 Python 與 Java 無法應用在實時軟件中，因為你必須要保證你的程序可以在一定時間內(nèi)完成運行。這并不是比拼運行速度，而是保障你的軟件在每次運行的時候都可以足夠迅速。

當然，C/C++ 如此受歡迎還有其他方面的因素：他們已經(jīng)存在了足夠長的時間來讓人們習慣他們了。但是他們同樣因為運行速度與運行結果的保障而受到追捧。然而不幸的是，這樣的速度是在犧牲內(nèi)存安全的前提下。更糟糕的是，許多實時軟件在保障速度的基礎上同樣需要注重安全性，例如車輛或者醫(yī)用機器人中的控制軟件。而這些軟件用的仍然是這些并不安全的語言。

在很長的一段時間里，二者處于魚與熊掌不可兼得的狀態(tài)，要么選擇運行速度和不可預知性，要么選擇內(nèi)存安全和可預知性。Rust 則完全顛覆了這一點，這也是它為什么令人激動的原因。

• 無需擔心數(shù)據(jù)的并發(fā)運算：只要程序中的不同部分可能在不同的時間或者亂序運行，并發(fā)就有可能發(fā)生。眾所周知，數(shù)據(jù)并發(fā)在多線程程序中是一個常見的危險因素，這一點我們稍后再詳細描述。

• 零開銷抽象：指編程語言提供的便利與表現(xiàn)力并不會帶來額外的負擔，也不會降低程序的運行速度。

• 不需要垃圾回收的內(nèi)存安全：內(nèi)存安全和垃圾回收的定義我們已經(jīng)了解了，接下來我們將詳細闡述 Rsut 是如何平衡速度與安全的關系的。

Rust 的內(nèi)存安全保障說簡單也很簡單，說復雜也是復雜。簡單是因為這里只包含了幾個非常容易理解的規(guī)則。

在 Rust 中，每一個對象有且只有一個所有者（owner），確保任何資源只能有一個綁定。為了避免被限制，在嚴格的規(guī)則下我們可以使用引用。引用在 Rsut 中經(jīng)常被稱作“借用（borrowing）”。

借用規(guī)則如下：

• 任何借用的作用域都能不大于其所有者的。

• 不能在擁有可變引用的同時擁有不可變引用，但是多個可變引用是可以的。

第一個規(guī)則避免了釋放重引用的發(fā)生，第二個規(guī)則排除了數(shù)據(jù)互斥的可能性。數(shù)據(jù)互斥會讓內(nèi)存處于未知狀態(tài)，而它可由這三個行為造成：

• 兩個或更多指針同時訪問同一數(shù)據(jù)。

• 至少有一個指針被用來寫入數(shù)據(jù)。

• 沒有同步數(shù)據(jù)訪問的機制。

當作者還是嵌入式工程師的時候，堆（heap）還沒有出現(xiàn)，于是便在硬件上設置了一個空指針解引用的陷阱，這樣一來，很多常見的內(nèi)存問題就顯得不是那么重要了。數(shù)據(jù)互斥是作者當時最怕的一種 bug；它難以追蹤，當你修改了一部分看起來并不重要的代碼，或是外部條件發(fā)生了微小的改變時，互斥的勝利者也就易位了。Therac-25 事件，就是因為數(shù)據(jù)互斥使得癌癥病人在治療過程中受到了過量的輻射，因此造成患者死亡或者重傷。

Rust 革新的關鍵也是它聰明的地方，它可以在編譯時強制執(zhí)行內(nèi)存安全保障。這些規(guī)則對任何接觸過數(shù)據(jù)互斥的人來說都應當不是什么新鮮事。

如作者之前所說，未定義行為發(fā)生的可能性是不能完全被清除的，這是由于底層計算機硬件固有的不安全性導致的。Rust 允許在一個存放不安全代碼的模塊進行不安全操作。C# 和 Ada 應該也有類似禁用安全檢查的方案。在進行嵌入式編程操作或者在底層系統(tǒng)編程的時候，就會需要這樣的一個塊。隔離代碼的潛在不安全部分非常有用，這樣一來，與內(nèi)存相關的錯誤就必定位于這個模塊內(nèi)，而不是整個程序的任意部分。

不安全模塊并不會關閉借用檢查，用戶可以在不安全塊中進行解引用裸引針，訪問或修改可變靜態(tài)變量，所有權系統(tǒng)的優(yōu)點仍然存在。

說起所有權，就不得不提起 C++ 的所有權機制。

C++ 中的所有權在 C++11 發(fā)布之后得到了極大的提升，但是它也為向后兼容性問題付出了不小的代價。對于作者來說，C++ 的所有權非常多余，以前簡單的值分類被吊打。不管怎么說，對 C++ 這樣廣泛使用的語言進行大規(guī)模優(yōu)化是一項偉大的成就，但是 Rust 卻是將所有權從一開始就當作核心理念進行設計的語言。

C++ 的類型系統(tǒng)不會對對象模型的生命周期進行建模，因此在運行時是無法檢查釋放后重引用的問題。C++ 的智能指針只是加在舊系統(tǒng)上的一個庫，而這個庫會以 Rust 中不被允許的方式濫用和誤用。

下面是作者在工作中編寫的一些經(jīng)過簡化后的代碼，代碼中存在誤用的問題。

這段代碼的作用是，通過字符串 dataCheckStrs 定義對某些數(shù)據(jù)的檢查，例如一個特定范圍內(nèi)的值，然后再通過解析這個字符串創(chuàng)建一個用于檢查對象的向量。

首先創(chuàng)建一個引用捕捉的 lambda 表達式，由 & 標識，這個智能指針（unique_ptr）指向的對象在這個 lambda 內(nèi)被移動，因此是非法的。

然后用被移動的數(shù)據(jù)構建的檢查填充向量，但問題是它只能完成第一步。unique_ptr 和被指向對象表示一種獨自占有的關系，不能被拷貝。所以在 std::transform 的第一個循環(huán)之后，unique_ptr 很有可能被清空，官方聲明是它會處于一種有效但是未知的狀態(tài)，但是以作者對 Clang 的經(jīng)驗來看它通常會被清空。

后續(xù)使用這個空指針時會導致未定義行為，作者運行之后得到了一個空指針錯誤，在大多數(shù)托管系統(tǒng)的空指針解引用都會報這種錯誤，因為零內(nèi)存頁面通常會被保留。但當然這種情況并不會百分百發(fā)生，這種 bug 在理論上可能會被暫時擱置一段時間，然后等著你的就是程序的突然崩潰。

這里使用 lambda 的方式很大程度上導致了這種危險的發(fā)生。編譯器在調(diào)用時只能看到以一個函數(shù)指針，它并不能像標準函數(shù)那樣檢查 lambda。

結合上下文來理解這個 bug 的話，最初使用 shared_ptr 來存儲數(shù)據(jù)，這一部分沒有問題。然而我們卻錯誤地將數(shù)據(jù)存儲在了 unique_ptr 里，當我們試圖進行更改時就會有問題，它并沒有引起注意是因為編譯器并沒有報錯。

這是 C++ 內(nèi)存安全問題并沒有引起重視的真實例子，作者和審核代碼的人直到一次測試前都沒有注意到這點。不管你有多少年的編程經(jīng)驗，這類 bug 根本躲不開！哪怕是編譯器都不能拯救你。這時就需要更好的工具了，不僅僅是為了我們的理智著想，也是為了公眾安全，這關乎職業(yè)道德。

接下來讓我們看一看同樣問題在 Rust 中的體現(xiàn)。

在 Rust 中，這種糟糕的 move 是不會被允許的。

這是我們第一次看到 Rust 的代碼。需要注意的是，默認情況下變量都是不可變的，但可以在變量前加 mut 關鍵詞使其可變，mut 類似于 C/C++ 中的 const 的反義詞。

Box 類型則表示我們已經(jīng)在堆上分配了內(nèi)存，在這里使用是因為 unique_ptr 同樣可以分配到堆。因為 Rust 中每個對象一次有且僅有一個所有者的規(guī)則，我們并不需要任何 unique_ptr 類似的東西。接著創(chuàng)建一個閉包，用更高階的函數(shù) map 轉換字符串，類似 C++ 的方式，但并不顯得冗長。但當編譯的時候還是會報錯，下面是錯誤信息：

Rust 社區(qū)有一點很棒，它提供給人們的學習資源非常多，也會提供可讀性的錯誤信息，用戶甚至可以向編譯器詢問關于錯誤的更詳細信息，而編譯器則會回復一個帶有解釋的最小示例。

當創(chuàng)建閉包時，由于有且僅有一個所有者的規(guī)則，數(shù)據(jù)是在其內(nèi)被移動的。接下來編譯器推斷閉包只能運行一次：沒有所有權的原因，多次的運行是非法的。之后 map 函數(shù)就會需求一個可以重復調(diào)用并且處于可變狀態(tài)的可調(diào)用函數(shù)，這就是為什么編譯器會失敗的原因。

這一段代碼顯示了 Rust 中類型系統(tǒng)與 C++ 相比有多么強大，同時也體現(xiàn)了在當編譯器跟蹤對象生命周期時的語言中編程是多么不同。

在示例中的錯誤信息里提到了特質（trait）。例如：”缺少實現(xiàn) FnMut 特質的閉包“。特質是一種告訴 Rust 編譯器某個特定類型擁有功能的語言特性，特質也是 Rust 多態(tài)機制的體現(xiàn)。

C++ 支持多種形式的多態(tài)，作者認為這有助于語言的豐富性。靜態(tài)多態(tài)中有模板、函數(shù)和以及操作符重載；動態(tài)多態(tài)有子類。但這些表達形式也有非常明顯的缺點：子類與父類之間的緊密耦合，導致子類過于依賴父類，缺乏獨立性；模板則因為其缺乏參數(shù)化的特性而導致調(diào)試困難。

Rust 中的 trait 則定義了一種指定靜態(tài)動態(tài)接口共享的行為。Trait 類似于其他語言中接口（interface）的功能，但 Rust 中只支持實現(xiàn)（implements）而沒有繼承（extends）關系，鼓勵基于組合的設計而不是實現(xiàn)繼承，降低耦合度。

下面來看一個簡單又有趣的例子：

首先定義一個名為 Rateable 的 trait，然后需要調(diào)用函數(shù) fluff_rating 并返回一個浮點數(shù)來實現(xiàn) Rateable。接著就是在 Alpaca 結構體上對 Rateable trait 的實現(xiàn)。下面是使用同樣的方法定義 Cat 類型。

在這段例子中作者使用了 Rust 的另一特性，模式匹配。它與 C 中的 switch 語句用法類似，但在語義上卻有很大的區(qū)別。switch 塊中的 case 只能用來跳轉，模式匹配中則要求覆蓋全部可能性才能編譯成功，但可選的匹配范圍和結構則賦予了其靈活性。

下面是這兩種類型的實現(xiàn)結合得出的通用函數(shù)：

尖括號中的是類型參數(shù)，這一點和 C++ 中相同，但與 C++ 模板的不同之處在于我們可以使函數(shù)參數(shù)化?！按撕瘮?shù)只適用于 Rateable 類型”的說法在 Rust 中是可以的，但在 C++ 中卻毫無意義，這帶來的后果不僅限于可讀性。類型參數(shù)上的 trait bound 意味著 Rust 的編譯器可以只對函數(shù)進行一次類型檢查，避免了單獨檢查每個具體的實現(xiàn)，從而縮短編譯時間并簡化了編譯錯誤信息。

Trait 也可以動態(tài)使用，雖然有的時候是必須的，但是并不推薦，因為會增加運行開銷，所以作者在本文中并沒有詳細提及。Trait 中另一大部分就是它的互通性，例如標準庫中的 Display 和 Add trait。實現(xiàn) add trait 意味著可以重載運算符 +，實現(xiàn) display trait 則意味著可以格式化輸出顯示。

C/C++ 中并沒有用于管理依賴的標準，倒是有不少工具可以提供幫助，但是它們的口碑都不是很好。基礎的 Makefiles 用于構建系統(tǒng)非常靈活，但在維護上就是一團垃圾。CMake 減少了維護的負擔，但是它的靈活性較弱，又很讓人煩惱。

Rust 在這方面就很優(yōu)秀，Cargo 是唯一 Rust 社區(qū)中唯一的可以用來管理包和依賴，同時還可以用來搭建和運行項目。它的地位與 Python 中的 Pipenv 和 Poetry 類似。官方安裝包會自帶 Cargo，它好用到讓人遺憾為什么 C/C++ 中沒有類似的工具。

這個問題沒有標準答案，完全取決于用戶的應用程序場景，這一點在任何編程語言中都是共通的。Rust 在不同方面都有成功的案例：包括微軟的 Azure IoT 項目，Mozilla 也支持 Rust 并將用于部分火狐瀏覽器中，同樣很多人也在使用 Rust。Rust 已經(jīng)日漸成熟并可以用于生產(chǎn)，但對于某些應用程序來說，它可能還不夠成熟或缺乏支持庫。

1、嵌入式：在嵌入式的環(huán)境中，Rust 的使用體驗完全由用戶定義用它做什么。Cortex-M 已經(jīng)資源成熟并可以用于生產(chǎn)了，RISC-V 也有了一個還在發(fā)展尚未常熟的工具鏈。.

x86 和 arm8 架構也發(fā)展得不錯，其中就有 Raspberry Pi。像是 PIC 和 AVR 這樣的老式架構還有些欠缺，但作者認為，對于大多數(shù)的新項目來說應該沒什么大問題。

交叉編譯支持也適用于所有的 LLVM（Low-Level Virtual Machine）的目標，因為 Rust 使用 LLVM 作為其編譯器后端。

Rust 在嵌入式中缺少的另一個部分是生產(chǎn)級的 RTOS，在 HAL 的發(fā)展也很匱乏。對許多項目來說，這沒什么大不了了，但對另一些項目的阻礙依舊存在。在未來幾年內(nèi)，阻礙可能還會繼續(xù)增加。

2、異步：語言的異步支持還尚在開發(fā)階段，async/await 的語法都還未被確定。

3、互通性：至于與其他語言的互操作性，Rust 有一個 C 的外部函數(shù)接口（FFI），無論是 C++ 到 Rust 函數(shù)的回調(diào)還是將 Rust 對象作為回調(diào)，都需要經(jīng)過這一步。在很多語言中這都是非常普遍的，在這里提到則是因為如果將 Rust 合并到現(xiàn)有的 C++ 項目中會有些麻煩，因為用戶需要在 Rust 和 C++ 中添加一個 C 語言層，這毫無疑問會帶來很多問題。

如果要在工作中從頭開始一個項目，那么作者絕對會選擇 Rust 編程語言。希望 Rust 可以成為一個更可靠，更安全，也更令人享受的未來編程語言。