“

也許這篇文章可以消除你對 Rust 的諸多誤解。

背景

Rustacean 是對Rust 編程語言[1]的用戶的稱呼。所以，「Rustacean 原則」可以看作是 Rust 官方團隊站在 Rust 語言用戶角度上創(chuàng)造 Rust 語言時所參考的原則。

“

Rustacean 是 Rust +? crustacean 的混合詞。crustacean 是指甲殼綱動物，所以 Rust 社區(qū)將螃蟹作為 Rust 語言的吉祥物，稱之為 Ferris，中文叫摩天蟹。值得明確的是，該吉祥物并非 Rust 官方指定的，最初由 Karen 在 rustacean.net[2] 網(wǎng)站公布了 Ferris 的概念藝術圖。

Rustacean 原則是由 Rust 語言團隊 Leader Niko 在 2021 年所發(fā)起的項目[3]，這個項目試圖列舉支配 Rust 設計和社區(qū)運作方式的原則。Niko 說，這些原則并非代表 Rust 官方而發(fā)布，只是他自己的觀點。建立原則的重點在于嘗試更好地發(fā)展原則并且在團隊中使用。

雖然這些是實驗性原則，但該原則在 Rust 官方內(nèi)部經(jīng)過一致性的討論和認可。從 Niko 今天發(fā)布的最新博客Rust 異步trait Part8[4] 和 談 “Rust 之魂”[5] 中也看得出來，該原則應該已經(jīng)在使用了。

“

去年的時候，因為 Niko 這篇 Rust 原則的文章還引發(fā)了社區(qū)的一些爭議。（前）Rust 核心團隊成員 Steve Klabnik 認為 Niko 這篇原則是以亞馬遜原則為藍本的，所以暗示亞馬遜在某種程度上對Rust的開發(fā)負責。亞馬遜雇傭了多名Rust維護者和貢獻者，但它只是眾多有員工參與的公司之一。Rust庫團隊負責人Mara Bos的觀點卻與之相反，她認為Steve的觀點“簡直是胡說八道”。事情經(jīng)過一年回頭再看原則的這些內(nèi)容，其實也沒有 Steve Klabnik 說的那么離譜，Rust 原則的內(nèi)容確實對 Rust Project 開發(fā)和貢獻有指導作用，讓大家知道力往哪里使。

今天打算寫這篇文章，和讀者朋友們一起學習一下 Rust 語言創(chuàng)造過程背后所遵循的原則，進一步理解 Rust 的設計哲學。值得說明的是，Rustacean 原則的大部分詳細內(nèi)容 Niko 并沒有寫完，所以這里有很多細節(jié)內(nèi)容是由我來補充的。

Rustacean 原則概要

Rustacean 原則主要分為兩部分內(nèi)容：

Rust 語言如何為用戶賦能，代表 Rust 和 用戶的契約

Rust 社區(qū)如何治理才能更貼近 Rustacean ，代表Rust 團隊成員和貢獻者之間的一種“契約”。

這份原則總的來說，是為 Rust 的總體目標服務的。Rust 的總體目標是：成為一門賦予每個人構建可靠且高效軟件能力的語言。

Rust 如何為用戶賦能

這部分原則內(nèi)容包括：

可靠性（ Reliable）。如果它編譯，它就可以工作。

高性能（ Performant）。既高效執(zhí)行又使用最少內(nèi)存。

支持性（ Supportive）。語言、工具和社區(qū)隨時為用戶提供幫助。

生產(chǎn)力（ Productive）。讓工作事半功倍。

透明性（ Transparent）。讓用戶可以預測和控制底層細節(jié)。

多樣性（ Versatile）。你可以用 Rust 做任何事。

Niko 所說的 “Rust 之魂”正是指 Rust 團隊在這幾個關鍵原則之間的斗爭——尤其是生產(chǎn)力、多樣性與透明性之間的權衡。

可靠性

具體而言，可靠性意味著要保證安全的 Rust 代碼可以避免未定義行為。類型安全是可靠性的關鍵要素。類型安全不是一種口頭建議，而是靠編譯器來管理。但是類型安全會增加語言的復雜性，讓 Rust 的學習變得更加困難。為此，Rust 團隊在錯誤信息和文檔上非常努力，以便減輕這種復雜性帶來的學習成本。正是因為這些成本，Rust 團隊才對Rust的類型系統(tǒng)試圖實現(xiàn)的東西施加了一些限制。

比如，對某些類型的錯誤條件采用了運行時檢查。并不試圖證明索引在范圍內(nèi)，而是檢查像vec[i]這樣的表達式，以確保i < vec.len()。在編譯時證明 i< vec.len() 會增加類型系統(tǒng)的復雜性，所以團隊選擇不這么做，盡管這樣會損失一些可靠性，但是增加了生產(chǎn)力。

再比如，允許用戶使用 Unsafe 代碼逃離類型系統(tǒng)的復雜性。比如，Safe Rust 不能表達雙向鏈表，但可以用 Unsafe Rust 來實現(xiàn)。然而，也希望用戶能夠封裝（安全抽象）他們的 Unsafe 代碼，向整個世界展示一個安全的界面。這與 Unsafe 代碼作者的生產(chǎn)力感覺相悖（考慮如何封裝東西更復雜），但對世界其他地方的可靠性卻有很大好處。

另一方面，Rust不隱藏錯誤條件，并鼓勵明確列出所有的可能性（或承認某些東西被忽略）。比如，Rust 要求用戶提供詳盡的 match 匹配分支，逼迫用戶去考慮所有情況。這樣做有助于提升 Rust 代碼的可靠性，但這是以降低用戶的生產(chǎn)力為代價的。所以，這是一個權衡。

錯誤處理就是一個很好的權衡案例。編程語言歷史長久以來，錯誤處理一般是使用異常。異常處理對用戶而言，提升了生產(chǎn)力。但是異常隱藏了控制流，用戶很難進行推理，在實踐中充滿了問題，對可靠性極大的不利。而Rust采用了函數(shù)式語言中首創(chuàng)的返回枚舉的方法，讓用戶強制考慮錯誤處理的方式，這有助于可靠性。其后又引入了?操作符，讓用戶更方便地傳播錯誤，是生產(chǎn)力的提升，同時確保錯誤路徑對用戶來說仍然是可見的，不會被完全忽略。

高性能

Rust 借鑒了 C++ 社區(qū)的零成本抽象概念。Cpp 之父 Bjarne 將零成本抽象定義為：“What you don't use, you don't pay for. And further: What you do use, you couldn't hand code any better”。零成本抽象意味著，用戶可以使用語言提供的高級抽象能力編寫代碼，而編譯器則會通過優(yōu)化為開發(fā)者生成高性能的代碼，進一步來說，就是將多余無用的代碼優(yōu)化掉，將有用的代碼優(yōu)化得更加高效。

（圖片來自于 2021 年Rust Dublin的輕talk： Zero Cost Abstractions[6]）

這份性能測試并非要踩 C#/Java 語言，只是為了突出 Rust 的零成本抽象能力的性能。你可以看到，Rust 提供了非常優(yōu)雅且和Java/C# 等同的高級迭代器抽象，而不會影響代碼的性能。

這也是被很多人誤會的一點，他們認為 Rust 宣傳的零成本抽象是百分之百的。但實際上想要保證百分之百零成本抽象是非常困難的，Rust 在這一方面也充滿了權衡。

Rust 的開發(fā)者認為，零成本抽象，不僅僅是追求零成本和最佳性能，還更應該著重改善用戶體驗，因為這就是抽象的意義所在。Rust 語言中的達到這個標準的零成本抽象特性只有少數(shù)的幾個，這些由 withoutboats 在他的博客中[7]列了出來：

Rust 所有權和借用機制。在沒有垃圾收集器的情況下保證內(nèi)存和線程安全是 Rust 最初的巨大成功故事。

迭代器和閉包 API。這是另一個經(jīng)典特性。就像上圖中所示的迭代器代碼一樣，你可以優(yōu)雅地使用各種過濾器、map和for循環(huán)，優(yōu)化出來的代碼和手寫的高效 C 代碼等價。

Async/Await 和 Future。Futures API 是一個重要的例子。早期的 Futures （指 0.3 版本之前）很好地達到了“零成本”的標準，但是沒有提供足夠好的用戶體驗。后來通過添加 Pin 來支持跨 await 的引用等，才達到一個用戶體驗良好的零成本抽象。

Unsafe Rust 和 模塊邊界（可見性）。這是 Rust 其他零成本抽象之母，因為這是 Safe Rust 的基礎。

除此之外的其他特性則沒有取得太大的成功，這有些例子：

trait 動態(tài)分發(fā)，目前沒有找到成功的解決方案。

泛型的trait限定，對優(yōu)化有一定阻礙，所以才引入了 特化（Specialization）。

NewType 模式，在某些情況下優(yōu)化并不理想（詳細可參考延伸閱讀reddit相關內(nèi)容）。

為什么百分百的零成本抽象這么難？因為 Rust 要考慮的因素太多。除了要為用戶提供體驗良好的抽象之外，還要對透明性和多樣性做權衡，這些都是對編譯器優(yōu)化干擾的因素。

很多人對 Rust 的另一個誤解就是，用 Rust 實現(xiàn)的代碼性能一定很好。但是實踐結果很有可能打破他們這層認知。開發(fā)者在使用 Rust 代碼的時候需要注意考慮以下幾個問題：

你的抽象有多少成本

你的代碼熱點路徑在哪（調(diào)用頻繁的代碼），該如何優(yōu)化

利用好性能基準測試

因為 Rust 零成本抽象并不保證用戶寫的 Rust 代碼性能最佳。

支持性

Rust 工具致力于為開發(fā)人員提供優(yōu)美、流暢的體驗。一個例子是編譯器如何提供高質量的錯誤消息，這些消息不僅試圖指示錯誤，而且還教用戶 Rust 語言是如何工作的，并就如何修復他們的代碼提供有用的建議。最近 Rust 官方還啟動了診斷信息多語言翻譯計劃，歡迎大家去貢獻。

對于像 cargo 這樣的工具，這體現(xiàn)在精心的 CLI 設計中，使“簡單的事情變得簡單”?；?Cargo 的有用的第三方插件變得越來越豐富。

生產(chǎn)力

生產(chǎn)力可能會與可靠性、高性能有沖突，所以這里也存在權衡?？梢詤⒖忌厦媪信e出來的 Rust 零成本抽象成功的幾個特性，比如所有權機制。很多人認為所有權機制影響生產(chǎn)力，是因為這種安全內(nèi)存管理方式比較新穎，接受起來沒有那么快。但是換成 GC 語言，開發(fā)者就沒有這個心智負擔，生產(chǎn)力自然提升。但熟練使用 Rust 的開發(fā)者則不會受這個影響。

讓 Rust 變得極具生產(chǎn)力的方法是什么？

Rust 致力于跨版本的穩(wěn)定性。這是因為穩(wěn)定性是生產(chǎn)力的關鍵推動因素：如果沒有跨版本的穩(wěn)定性，用戶將被迫花時間解決構建失敗，而不是構建用戶想要構建的功能。但是這種穩(wěn)定性也會阻礙 Rust 語言開發(fā)者們對語言特性設計的自由度，所以引入了 Edition 系統(tǒng)讓設計自由度和語言版本穩(wěn)定性達到平衡。

可移植性。默認情況下，Rust 代碼旨在跨所有主流架構移植。

打造繁榮的生態(tài)系統(tǒng)。

透明性

Rust 官方團隊非常重視透明性。透明性是 Rust 提供給用戶的底層掌控力，但需要注意并不意味著它能幫用戶自動提升性能。

但透明性暴露的底層控制細節(jié)，讓多樣性和生產(chǎn)力大打折扣。比如 repr屬性，再比如異步函數(shù)中隨處可見的 Box>>。因為它會迫使用戶過度關注對當前要解決問題實際并不重要的底層細節(jié)。

透明性與多樣性、生產(chǎn)力有所沖突，在設計語言特性時需要仔細權衡。

多樣性

Rust 同樣重視多樣性，多樣性意味著通用性，意味著 Rust 可以做上層的應用，也可以做底層的系統(tǒng)開發(fā)。

官方的目標是以某種方式向 Rust 程序公開所有核心系統(tǒng)功能，即使訪問或正確使用它們可能很困難。而不希望 Rust 用戶覺得他們必須選擇 C 或其他語言，他們應該能夠使用 Unsafe Rust 來完成他們的工作。像“內(nèi)聯(lián)匯編”這樣的功能也遵循這種思路。

我能想到一個比較典型的例子是，Rust 將 Error trait 移動到了 core 中，這樣就可以統(tǒng)一 std 和 no_std 的錯誤處理了。

Rust 社區(qū)如何治理才能更貼近 Rustacean

該部分內(nèi)容提供了以下一些原則，用于幫助 Rust 核心團隊和社區(qū)貢獻者良好合作：

善良體貼。相互尊重彼此才是構建 Rust 未來的基礎。

給用戶帶來快樂。首要目標是讓 Rust 用戶更有效率和能力。希望人們喜歡使用 Rust，如果他們愿意，也喜歡參與它的社區(qū)。

暢所欲言地表達自己。帶上你的專業(yè)知識，并愿意為你認為正確的事情進行辯論。

認可別人的知識。沒有人能壟斷好的創(chuàng)意。Rust 團隊需要汲取優(yōu)秀的建議來改進設計。

從小處開始。尋找完美的設計需要迭代。大處著眼，小處著手；當你了解更多時，不要害怕改變。

跟進。說你會做的，做你說的。

把愛傳出去。Rust項目成員需要識別有潛力的貢獻者，有義務去發(fā)展新的成員，并且當好教練的角色。

信任和委托。賦予他人權力意味著愿意讓他們以他們認為最好的方式做出決定。

P.S 金發(fā)姑娘原則

在 Niko 的博客中還提到一個金發(fā)姑娘原則（Goldilocks），比較有趣。

該原則出自一個英國的童話故事《金發(fā)姑娘和三只熊》。

講的是一位金發(fā)姑娘偷偷跑進熊的家里，她發(fā)現(xiàn)了三碗粥、三把椅子和三張床，粥有冷的、有熱的；椅子有硬的、有軟的；床有大的、有小的。她都嘗了、都試了以后，選擇了不冷不熱的那碗粥，不硬不軟的那把椅子，不大不小的那張床，因為那碗粥、那把椅子、那張床最適合她，對她來說都是“剛剛好”，這種選擇的原則就叫做“金發(fā)姑娘原則”。

“金發(fā)姑娘原則”被應用在各個領域，比如發(fā)展心理學、經(jīng)濟學、通訊科學、醫(yī)學和天體生物學、溝通等等。

如果把該原則用在如何看待（新）事物方面，那么它會成為一個非常好的思維工具。通過該原則，可以讓你避免用非黑即白的思維看待這個世界存在的事物，比如 Rust 語言，比如某個人。這個世界并不是好與壞、黑與白這兩個極端，它還存在中間狀態(tài)。

小結

本文可能還缺少很多細節(jié)，但總體上我認為應該把 Rustacean 原則和 Niko 所說的 Rust 之魂講清楚了。Rust 語言并不完美，但它在這些原則之間不斷權衡而發(fā)展。我們可以不完美，也不可能完美，但不能不追求完美。感謝閱讀。

審核編輯 ：李倩