“
也許這篇文章可以消除你對 Rust 的諸多誤解。
背景
Rustacean 是對Rust 編程語言[1]的用戶的稱呼。所以,「Rustacean 原則」可以看作是 Rust 官方團隊站在 Rust 語言用戶角度上創造 Rust 語言時所參考的原則。
“
Rustacean 是 Rust +? crustacean 的混合詞。crustacean 是指甲殼綱動物,所以 Rust 社區將螃蟹作為 Rust 語言的吉祥物,稱之為 Ferris,中文叫摩天蟹。值得明確的是,該吉祥物并非 Rust 官方指定的,最初由 Karen 在 rustacean.net[2] 網站公布了 Ferris 的概念藝術圖。
Rustacean 原則是由 Rust 語言團隊 Leader Niko 在 2021 年所發起的項目[3],這個項目試圖列舉支配 Rust 設計和社區運作方式的原則。Niko 說,這些原則并非代表 Rust 官方而發布,只是他自己的觀點。建立原則的重點在于嘗試更好地發展原則并且在團隊中使用。
雖然這些是實驗性原則,但該原則在 Rust 官方內部經過一致性的討論和認可。從 Niko 今天發布的最新博客Rust 異步trait Part8[4] 和 談 “Rust 之魂”[5] 中也看得出來,該原則應該已經在使用了。
“
去年的時候,因為 Niko 這篇 Rust 原則的文章還引發了社區的一些爭議。(前)Rust 核心團隊成員 Steve Klabnik 認為 Niko 這篇原則是以亞馬遜原則為藍本的,所以暗示亞馬遜在某種程度上對Rust的開發負責。亞馬遜雇傭了多名Rust維護者和貢獻者,但它只是眾多有員工參與的公司之一。Rust庫團隊負責人Mara Bos的觀點卻與之相反,她認為Steve的觀點“簡直是胡說八道”。事情經過一年回頭再看原則的這些內容,其實也沒有 Steve Klabnik 說的那么離譜,Rust 原則的內容確實對 Rust Project 開發和貢獻有指導作用,讓大家知道力往哪里使。
今天打算寫這篇文章,和讀者朋友們一起學習一下 Rust 語言創造過程背后所遵循的原則,進一步理解 Rust 的設計哲學。值得說明的是,Rustacean 原則的大部分詳細內容 Niko 并沒有寫完,所以這里有很多細節內容是由我來補充的。
Rustacean 原則概要
Rustacean 原則主要分為兩部分內容:
Rust 語言如何為用戶賦能,代表 Rust 和 用戶的契約
Rust 社區如何治理才能更貼近 Rustacean ,代表Rust 團隊成員和貢獻者之間的一種“契約”。
這份原則總的來說,是為 Rust 的總體目標服務的。Rust 的總體目標是:成為一門賦予每個人構建可靠且高效軟件能力的語言。
Rust 如何為用戶賦能
這部分原則內容包括:
可靠性( Reliable)。如果它編譯,它就可以工作。
高性能( Performant)。既高效執行又使用最少內存。
支持性( Supportive)。語言、工具和社區隨時為用戶提供幫助。
生產力( Productive)。讓工作事半功倍。
透明性( Transparent)。讓用戶可以預測和控制底層細節。
多樣性( Versatile)。你可以用 Rust 做任何事。
Niko 所說的 “Rust 之魂”正是指 Rust 團隊在這幾個關鍵原則之間的斗爭——尤其是生產力、多樣性與透明性之間的權衡。
可靠性
具體而言,可靠性意味著要保證安全的 Rust 代碼可以避免未定義行為。類型安全是可靠性的關鍵要素。類型安全不是一種口頭建議,而是靠編譯器來管理。但是類型安全會增加語言的復雜性,讓 Rust 的學習變得更加困難。為此,Rust 團隊在錯誤信息和文檔上非常努力,以便減輕這種復雜性帶來的學習成本。正是因為這些成本,Rust 團隊才對Rust的類型系統試圖實現的東西施加了一些限制。
比如,對某些類型的錯誤條件采用了運行時檢查。并不試圖證明索引在范圍內,而是檢查像vec[i]這樣的表達式,以確保i < vec.len()。在編譯時證明 i< vec.len() 會增加類型系統的復雜性,所以團隊選擇不這么做,盡管這樣會損失一些可靠性,但是增加了生產力。
再比如,允許用戶使用 Unsafe 代碼逃離類型系統的復雜性。比如,Safe Rust 不能表達雙向鏈表,但可以用 Unsafe Rust 來實現。然而,也希望用戶能夠封裝(安全抽象)他們的 Unsafe 代碼,向整個世界展示一個安全的界面。這與 Unsafe 代碼作者的生產力感覺相悖(考慮如何封裝東西更復雜),但對世界其他地方的可靠性卻有很大好處。
另一方面,Rust不隱藏錯誤條件,并鼓勵明確列出所有的可能性(或承認某些東西被忽略)。比如,Rust 要求用戶提供詳盡的 match 匹配分支,逼迫用戶去考慮所有情況。這樣做有助于提升 Rust 代碼的可靠性,但這是以降低用戶的生產力為代價的。所以,這是一個權衡。
錯誤處理就是一個很好的權衡案例。編程語言歷史長久以來,錯誤處理一般是使用異常。異常處理對用戶而言,提升了生產力。但是異常隱藏了控制流,用戶很難進行推理,在實踐中充滿了問題,對可靠性極大的不利。而Rust采用了函數式語言中首創的返回枚舉的方法,讓用戶強制考慮錯誤處理的方式,這有助于可靠性。其后又引入了?操作符,讓用戶更方便地傳播錯誤,是生產力的提升,同時確保錯誤路徑對用戶來說仍然是可見的,不會被完全忽略。
高性能
Rust 借鑒了 C++ 社區的零成本抽象概念。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”。零成本抽象意味著,用戶可以使用語言提供的高級抽象能力編寫代碼,而編譯器則會通過優化為開發者生成高性能的代碼,進一步來說,就是將多余無用的代碼優化掉,將有用的代碼優化得更加高效。
(圖片來自于 2021 年Rust Dublin的輕talk: Zero Cost Abstractions[6])
這份性能測試并非要踩 C#/Java 語言,只是為了突出 Rust 的零成本抽象能力的性能。你可以看到,Rust 提供了非常優雅且和Java/C# 等同的高級迭代器抽象,而不會影響代碼的性能。
這也是被很多人誤會的一點,他們認為 Rust 宣傳的零成本抽象是百分之百的。但實際上想要保證百分之百零成本抽象是非常困難的,Rust 在這一方面也充滿了權衡。
Rust 的開發者認為,零成本抽象,不僅僅是追求零成本和最佳性能,還更應該著重改善用戶體驗,因為這就是抽象的意義所在。Rust 語言中的達到這個標準的零成本抽象特性只有少數的幾個,這些由 withoutboats 在他的博客中[7]列了出來:
Rust 所有權和借用機制。在沒有垃圾收集器的情況下保證內存和線程安全是 Rust 最初的巨大成功故事。
迭代器和閉包 API。這是另一個經典特性。就像上圖中所示的迭代器代碼一樣,你可以優雅地使用各種過濾器、map和for循環,優化出來的代碼和手寫的高效 C 代碼等價。
Async/Await 和 Future。Futures API 是一個重要的例子。早期的 Futures (指 0.3 版本之前)很好地達到了“零成本”的標準,但是沒有提供足夠好的用戶體驗。后來通過添加 Pin 來支持跨 await 的引用等,才達到一個用戶體驗良好的零成本抽象。
Unsafe Rust 和 模塊邊界(可見性)。這是 Rust 其他零成本抽象之母,因為這是 Safe Rust 的基礎。
除此之外的其他特性則沒有取得太大的成功,這有些例子:
trait 動態分發,目前沒有找到成功的解決方案。
泛型的trait限定,對優化有一定阻礙,所以才引入了 特化(Specialization)。
NewType 模式,在某些情況下優化并不理想(詳細可參考延伸閱讀reddit相關內容)。
為什么百分百的零成本抽象這么難?因為 Rust 要考慮的因素太多。除了要為用戶提供體驗良好的抽象之外,還要對透明性和多樣性做權衡,這些都是對編譯器優化干擾的因素。
很多人對 Rust 的另一個誤解就是,用 Rust 實現的代碼性能一定很好。但是實踐結果很有可能打破他們這層認知。開發者在使用 Rust 代碼的時候需要注意考慮以下幾個問題:
你的抽象有多少成本
你的代碼熱點路徑在哪(調用頻繁的代碼),該如何優化
利用好性能基準測試
因為 Rust 零成本抽象并不保證用戶寫的 Rust 代碼性能最佳。
支持性
Rust 工具致力于為開發人員提供優美、流暢的體驗。一個例子是編譯器如何提供高質量的錯誤消息,這些消息不僅試圖指示錯誤,而且還教用戶 Rust 語言是如何工作的,并就如何修復他們的代碼提供有用的建議。最近 Rust 官方還啟動了診斷信息多語言翻譯計劃,歡迎大家去貢獻。
對于像 cargo 這樣的工具,這體現在精心的 CLI 設計中,使“簡單的事情變得簡單”。基于 Cargo 的有用的第三方插件變得越來越豐富。
生產力
生產力可能會與可靠性、高性能有沖突,所以這里也存在權衡。可以參考上面列舉出來的 Rust 零成本抽象成功的幾個特性,比如所有權機制。很多人認為所有權機制影響生產力,是因為這種安全內存管理方式比較新穎,接受起來沒有那么快。但是換成 GC 語言,開發者就沒有這個心智負擔,生產力自然提升。但熟練使用 Rust 的開發者則不會受這個影響。
讓 Rust 變得極具生產力的方法是什么?
Rust 致力于跨版本的穩定性。這是因為穩定性是生產力的關鍵推動因素:如果沒有跨版本的穩定性,用戶將被迫花時間解決構建失敗,而不是構建用戶想要構建的功能。但是這種穩定性也會阻礙 Rust 語言開發者們對語言特性設計的自由度,所以引入了 Edition 系統讓設計自由度和語言版本穩定性達到平衡。
可移植性。默認情況下,Rust 代碼旨在跨所有主流架構移植。
打造繁榮的生態系統。
透明性
Rust 官方團隊非常重視透明性。透明性是 Rust 提供給用戶的底層掌控力,但需要注意并不意味著它能幫用戶自動提升性能。
但透明性暴露的底層控制細節,讓多樣性和生產力大打折扣。比如 repr屬性,再比如異步函數中隨處可見的 Box
透明性與多樣性、生產力有所沖突,在設計語言特性時需要仔細權衡。
多樣性
Rust 同樣重視多樣性,多樣性意味著通用性,意味著 Rust 可以做上層的應用,也可以做底層的系統開發。
官方的目標是以某種方式向 Rust 程序公開所有核心系統功能,即使訪問或正確使用它們可能很困難。而不希望 Rust 用戶覺得他們必須選擇 C 或其他語言,他們應該能夠使用 Unsafe Rust 來完成他們的工作。像“內聯匯編”這樣的功能也遵循這種思路。
我能想到一個比較典型的例子是,Rust 將 Error trait 移動到了 core 中,這樣就可以統一 std 和 no_std 的錯誤處理了。
Rust 社區如何治理才能更貼近 Rustacean
該部分內容提供了以下一些原則,用于幫助 Rust 核心團隊和社區貢獻者良好合作:
善良體貼。相互尊重彼此才是構建 Rust 未來的基礎。
給用戶帶來快樂。首要目標是讓 Rust 用戶更有效率和能力。希望人們喜歡使用 Rust,如果他們愿意,也喜歡參與它的社區。
暢所欲言地表達自己。帶上你的專業知識,并愿意為你認為正確的事情進行辯論。
認可別人的知識。沒有人能壟斷好的創意。Rust 團隊需要汲取優秀的建議來改進設計。
從小處開始。尋找完美的設計需要迭代。大處著眼,小處著手;當你了解更多時,不要害怕改變。
跟進。說你會做的,做你說的。
把愛傳出去。Rust項目成員需要識別有潛力的貢獻者,有義務去發展新的成員,并且當好教練的角色。
信任和委托。賦予他人權力意味著愿意讓他們以他們認為最好的方式做出決定。
P.S 金發姑娘原則
在 Niko 的博客中還提到一個金發姑娘原則(Goldilocks),比較有趣。
該原則出自一個英國的童話故事《金發姑娘和三只熊》。
講的是一位金發姑娘偷偷跑進熊的家里,她發現了三碗粥、三把椅子和三張床,粥有冷的、有熱的;椅子有硬的、有軟的;床有大的、有小的。她都嘗了、都試了以后,選擇了不冷不熱的那碗粥,不硬不軟的那把椅子,不大不小的那張床,因為那碗粥、那把椅子、那張床最適合她,對她來說都是“剛剛好”,這種選擇的原則就叫做“金發姑娘原則”。
“金發姑娘原則”被應用在各個領域,比如發展心理學、經濟學、通訊科學、醫學和天體生物學、溝通等等。
如果把該原則用在如何看待(新)事物方面,那么它會成為一個非常好的思維工具。通過該原則,可以讓你避免用非黑即白的思維看待這個世界存在的事物,比如 Rust 語言,比如某個人。這個世界并不是好與壞、黑與白這兩個極端,它還存在中間狀態。
小結
本文可能還缺少很多細節,但總體上我認為應該把 Rustacean 原則和 Niko 所說的 Rust 之魂講清楚了。Rust 語言并不完美,但它在這些原則之間不斷權衡而發展。我們可以不完美,也不可能完美,但不能不追求完美。感謝閱讀。
審核編輯 :李倩
-
編程語言
+關注
關注
10文章
1942瀏覽量
34711 -
Rust
+關注
關注
1文章
228瀏覽量
6601
原文標題:Rustacean 原則 與 Rust 之魂
文章出處:【微信號:Rust語言中文社區,微信公眾號:Rust語言中文社區】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論