2021 年 Rust 生態調研報告 | 星辰大海【上篇】

本文轉載自公眾號：覺學社
作者：張漢東，獨立諮詢師/《Rust程式設計之道》作者

文前

半年前，我寫了一篇《三萬言｜2021 年 Rust 行業調研報告》[1] ，內容主要圍繞 Rust 語言介紹和行業領域開源應用盤點兩大部分內容。時隔半年，我覺得有必要再寫一篇年終的Rust 生態調研報告。因為我想給大家提供一個比較全面的視角，通過挖掘網際網路上的各種散落且隱藏的資訊，最終繪製出一張 Rust 的“生態地圖”，讓大家儘量客觀公正地去認識 Rust 語言。

在完成本篇報告之後，我得出一個觀點：Rust 的出現並不是要你去用它重寫一切，而是希望你可以用它創造新的未來。當然這只是我個人觀點，不代表任何人任何機構和公司。如果您有不同觀點，歡迎探討。

本次報告的所有內容都來自於網際網路公開資訊，如有錯誤或不宜在本報告中提及的內容，請及時告知。

大綱

本次報告包含以下內容：

Rust 在各個領域中的應用狀態和趨勢
Rust 職業崗位分佈
Rust 語言在高校教育的普及狀態
Rust Project 自身狀態

截止 2021年底，距離 Rust 語言2015年5月15日正式釋出已經長達六年半的時間。在這六年半的時間內，Rust 每隔三年釋出一個大版本，叫做 Edition，中文翻譯為版次。

版次這個翻譯來自於書籍出版術語。比如《Rust 程式設計之道》第一版、第二版等。

版次（Edition）的意義

版次（edition）的引入主要是為了 Rust 能在發展過程中方便地引入一些不向後相容的特性，而不會影響之前的程式碼。比如 Rust 2018 edition中沒有 async / await 關鍵字，但是在 2021 editon 中引入了 async/await 關鍵字，這樣就避免破壞舊程式碼中 let async = 1;這樣的寫法。版次和語義化版本是正交的概念。

Rust 釋出的每個版次都有其核心主題意義：

2015 Edition：主題是「穩定性（Stability）」。2015 edition 代表 Rust 語言 1.0 將趨於穩定。在 1.0 之前 Rust 每天都在變化，而 1.0 之後則意味著團隊會致力於向後相容，這樣開發者才能穩定地使用 Rust 構建專案。版次的概念其實在2017年才引入，所以將 2015年正式釋出之前的語義版本號，即 1.0 之前，都歸為 2015 edition。
2018 Edition：主題是「生產力（Productivity）」。2018 edition 中引入的內容大部分是向後相容的，即，在2015 中可以使用其中一些特性，比如對借用檢查的改進NLL。但是對模組系統的改進則只能用於 2018 edition 中。2018 eidtion 既然是以生產力為主題，那麼特性的優先順序都會優先服務於這個主題。
2021 Edition：主題是「成熟（Mature）」。2021 edition 並沒有引入太多新特性，而是清理了一些技術債務，比如持續對 Rust 編譯器進行重構和改進，包括內部使用的新的 trait 系統chalk 和 query 系統（開源版本：https://github.com/nikomatsak...）。另外還處理了一些向後相容的問題，以及持續投入一些影響未來發展的關鍵特性，比如常量泛型、泛型關聯型別等。

Rust Edition 現在已經確定了，每三年釋出一個版次。這就意味著 Rust 每三年都會圍繞一個引領 Rust 發展的主題。

2024 Edition 展望

2024 Edition：主題也許是「廣泛應用」。

2021 年 2 月 9 號，Rust 基金會宣佈成立。華為、AWS、Google、微軟、Mozilla、Facebook 等科技行業領軍巨頭加入 Rust 基金會，成為白金成員，以致力於在全球範圍內推廣和發展 Rust 語言。

隨後，ARM 、AUTOMATA、1PASSword、豐田汽車、動視、Knoldus [2] 、Tangram [3] 等各個領域中對未來充滿野心的公司都加入了基金會，為推動 Rust 做貢獻。

最近 Rust 基金會又推選在非營利組織有十五年經驗的 Rebecca 稱為了基金會的執行董事（ED）和CEO。相信在 Rust 基金會的領導下， Rust 會有廣泛的應用前景。

Rust Project 機遇與挑戰

Rust 語言是完全開源的，它也是世界上最大的開源社群組織。由不同職責的團隊和工作組共同協作。具體可以在 Rust 官網 [4]看到相關資訊。目前擁有 3539 個貢獻者。

截止目前，crates.io [5]上面 crates 的下載總量達到 11,012,362,794 次，即 110 億次。

我們可以通過這些指標來評判一下 Rust 的成熟度。

使用者數：Rust 連續六年是使用者最受歡迎的語言，但實際使用者數，可以從 TIOBE 程式語言排行榜中看出來，截止 2021年11月，Rust 排名 29 ，流行度是 0.54% 。任何沒有進入 TIOBE 榜單前20的語言，其實都還需要進行營銷和宣傳，這意味著 Rust 依舊屬於小眾語言。
貢獻者數量。Rust 貢獻者數量截止目前為 3539 個。我們對比一下Github開源的其他語言：流行的 Go 語言目前貢獻者是 1758個；Kotlin 目前的貢獻者是 516 個。看一下流行的框架 Rails 的貢獻者是 4379個。相對而言，Rust 語言貢獻者是相當多的。
錯誤修復/補丁頻率。根據 Github issues 相關資料， Rust 目前肉眼可見每小時平均修復一個 issue 問題。從 2010年 6月17號 Rust 創始人 Graydon 的第一個提交開始，一共修復了 33942 個issues 和 49011 個 PR，十年間按 3832天計算，平均一天修復 8 個 issue，13 個 PR。
未解決問題數。目前有 7515 個開放的問題，如果按上面的平均問題修復頻率來計算，預計 3 年左右可以修復完畢。3年以後，又是新的 Edition 釋出：2024 Edtion。
儲存庫統計：目前 star 數有 60500 個，watch 數有 15000 個。
StackOverflow 問題數量：Rust 相關問題一共有 24924 個，平均每週 150 個問題左右，每天 20 個問題左右。相比其他語言，javascript 問題 2299100 個，Java 問題 1811376 個， Go 問題 57536 個，C 問題 368957 個，Cpp 問題 745313 個。相比於 Go ， Rust 的問題數幾乎是它的一半。
新特性發布頻率：Rust 穩定版每六週發一個新版。
是否穩定：Rust 早已穩定。
API更改頻率：穩定版 API 基本不會更改。
是否存在“核心”開發人員：Rust 核心開發人員非常多，按工作小組來組織分配，參考 Rust 團隊治理[6]
文件數量和質量：API 文件、書籍、教程和部落格。Rust API 文件相當成熟和先進，目前國內外 Rust 書籍也越來越豐富，Rust Weekly 每週都會發布社群很多 Rust 相關部落格、視訊等文章。
社群響應頻率：有經驗的使用者如何幫助新使用者。Rust 社群國內外都有，通過群組織、論壇、線下活動等幫助社群成員進行交流。
商業支援度：Rust 基金會已經成立：Google、華為、微軟、亞馬遜、Facebook、Mozilla 、豐田、動視等公司都是其董事成員。
知名專案和產品應用的數量：開源 CNCF 的一些知名專案：資料庫（TiKV）、雲原生（Linkerd，Krustlet）、事件流系統（Tremor），還有 Google Andriod 、亞馬遜、微軟等都支援 Rust 開發，區塊鏈（Near、Solana、 Parity等）。國內使用 Rust 的公司：螞蟻金服、PingCAP、位元組跳動、祕猿、溪塔、海致星圖、非凸科技等。還有很多優秀的專案或產品這裡沒有列出來。
“恐怖事故”的數量，如果沒有這一項，則證明它並未在實際具有挑戰性的生產環境中使用。Rust 有專門的資訊保安工作組，並且有專門的網站記錄 Rust 生態中相關“恐怖事故” : https://rustsec.org/[7] 。
工具鏈支援：新的連結器支援（mold[8]）/ 新的 trace 工具（tracy[9]）/ profiler 商業產品也支援 Rust 了（superluminal[10]）等等。

如果拿植物的成長階段（「播種- 發芽 - 開花 - 結果」）來類比的話，Rust 的成熟度應該屬於「開花」階段。

Rust 語言作為一門新生語言，雖然目前倍受歡迎，但是面臨的挑戰還很多。

挑戰主要來自兩個方面：

領域的選擇。一門語言唱的再好，如果不被應用，也是沒有什麼用處。Rust 語言當前面臨的挑戰就是在領域中的應用。而目前最受關注的是，Rust 進入 Linux 核心開發，如果成功，其意義是劃時代的。
語言自身特性的進化。Rust 語言還有很多特性需要支援和進化，這裡羅列了一些待完善的相關特性。

關於領域的選擇，我們在下一節「Rust 在各個領域中的應用狀態和趨勢」中探討。先來看看 Rust 語言自身還有哪些特性需要進化才能順利完成 2024 Edition 的階段目標。

Rust 語言記憶體安全初步成果顯現

據 2021年12月31日釋出於 arXiv 的論文《SOK: On the Analysis of Web Browser Security》[11] 中所言：

比較了四種瀏覽器架構，以及近十年來瀏覽器中記憶體安全問題依然是主流。但是觀察 Firefox 通過 Oxidation 專案（Rust）替換了 12% 的元件。自2015年以來，Firefox 的記憶體安全漏洞數量出現了小幅但穩定的下降，其中，渲染器的記憶體安全漏洞明顯下降。

“Oxidation[12] 是專門用於將 Rust 程式碼整合到 Firefox 中的一個專案。Firefox 54 以來，所有平臺都需要 Rust 支援，並且第一個主要的 Rust 元件是在 Firefox 56 (encoding_rs) 和 57 (Stylo) 中釋出的。展望未來，Oxidation 的目標是讓在 Firefox 中使用 Rust 變得更容易和更高效，並相應地增加 Firefox 中的 Rust 程式碼量。

可以說經過六年的應用，Rust 語言的記憶體安全保障終於看到了初步的效果。該論文建議瀏覽器供應商遵循這一最佳實踐，並逐步將他們的瀏覽器轉向記憶體安全的語言。

待完善的 Rust 語言特性

Rust 語言必須解決以下問題才能順利往前發展：

錯誤處理改進 。在 RFC 3058[13] 中描述了 Try trait 的改進，為了達成錯誤處理大一統。
安全 I/O。最近Rust官方合併了一個 RFC 3128[14] ，通過引入I/O安全的概念和一套新的型別和特質，為AsRawFd和相關特質的使用者提供關於其原始資源控制程式碼的保證，從而彌補Rust中封裝邊界的漏洞。
泛型關聯型別 GAT。泛型關聯型別在 RFC 1598 [15] 中被定義。該功能特性經常被對比於 Haskell 中的 HKT(Higher Kinded Type)，即高階型別。雖然類似，但是 Rust 並沒有把 Haskell 的 HKT 原樣照搬，而是針對 Rust 自身特性給出 GAT(Generic associated type) 的概念。
泛型特化（Specialization）。泛型特化這個概念，對應 Cpp 的模版特化。但是 Cpp 對特化的支援是相當完善，而 Rust 中特化還未穩定。在 RFC #1210[16] 中定義了 Rust 的泛型特化的實現標準，在 issue #31844[17] 對其實現狀態進行了跟蹤。目前還有很多未解決的問題。
非同步：async trait && async drop。Rust 目前非同步雖然早已穩定，但還有很多需要完善的地方。為此，官方建立了非同步工作組，並且建立了非同步基礎計劃[18] 來推動這一過程。另外，官方也開啟了非同步執行時標準化的討論，為了達成可移植性和可互操性的非同步執行時在努力中。
協程的穩定化。目前 Rust 的非同步是基於一種半協程機制生成器（ Generator）來實現的，但生成器特性並未穩定。圍繞生成器特性穩定的話題在 Rust 論壇不定期會提出，因為生成器特性在其他語言中也是比較常見且有用的特性。
可移植的 SIMD。Rust 官方團隊釋出了 portable-simd[19] ，你可以在 Nightly 下使用這個庫來代替 packed_simd[20] 了。這個庫使得用 Rust 開發跨平臺 SIMD 更加容易和安全。在不久的將來，也會引入到標準庫中穩定下來。
新的 asm! 支援。asm! 巨集允許在 Rust 中內聯彙編。在 RFC #2873[21] 中規定了新的 asm!巨集語法，將用於相容 ARM、x86 和 RISC-V 架構等，方便在未來新增更多架構支援。之前的 asm! 巨集被重新命名為 llvm_asm!。目前新的 asm! 已經接近穩定狀態，可在 issue #72016[22] 中跟蹤。總的來說，就是讓 asm! 巨集更加通用，相比於 llvm_asm!，它有更好的語法。
Rustdoc 提升。Rust 是一門優雅的語言。並且這份優雅是非常完整的。除了語言的諸多特性設計優雅之外，還有一個亮點就是 Rustdoc。Rust 官方 doc 工作組勵志讓 Rustdoc 成為一個偉大的工具。Rustdoc 使用簡單，可以建立非常漂亮的頁面，並使編寫文件成為一種樂趣。關於 Rustdoc 詳細介紹你可以去看 Rustdoc book[23] 。
持續穩定 Rust for Linux 未穩定特性心願單[24] 中所列清單。這個是和 Rust for Linux 團隊一起完成的。
新的 GCC 後端。為了推動 Rust for Linux ，Rust 支援新的 GCC後端也是早已提上日程的事了。其中 rustc_codegen_gcc進展最快，目前已通過了部分的 rustc 測試，rustc_codegen_llvm是目前的主要開發專案，Rust GCC預計在 1~2 年內完成。
穩定分配器 API 。新增標準分配器介面並支援使用者定義的分配器，允許不同的集合支援不同的分配器，等等。具體在 RFC 1398[25] 中有完整描述。目前狀態是為 Vec<T> 增加了一個分配器泛型引數。

上面羅列的只是 Rust 待完善問題的一部分工作而已，還有很多內容沒有列出來。Rust 語言還在不斷進化中。

Rust 開源治理中凸顯的問題

今年 Rust 開源組織發生了Rust 語言稽核團隊（mod team）集體離職的事件，引起國內外技術社群廣泛討論。

據官方描述[26]矛盾產生於稽核團隊和核心團隊成員之間關於如何處理稽核問題時造成的分歧。因為這些矛盾涉及了很多相關人員很多個人隱私，所以官方也不能透露更多內幕資訊，這就導致外界對這件事有很多猜測和誇大影響。這件事本來也就是 Rust 官方團隊內部事件，其實根本沒有必要讓外界知道。

要管理一個規模超過大多數公司，卻由志願者組成的開源專案是很困難的。他們有很多工作要做，但他們相信Rust Project會因此變得更加強大。雖然這些問題很嚴重，需要謹慎地得出積極的結論，但他們相信這不會對Rust語言及其核心工具、文件和支援進行改進的能力產生負面影響。

對於關心 Rust 的中文社群的朋友和技術媒體而言，我覺得沒必要過度解讀。因為我們不瞭解美國社會以及處於該社會下人們所關心和敏感的問題是什麼，真正想去理解也是比較困難的，因為有文化差異。我們只知道，這是一個超過大多數公司人員規模且都是志願者組成的開源組織所要面臨和解決的問題，問題一旦經過解決，那麼這個社群將得到進化，會更加強大。所以沒必要擔心什麼 Rust 會被負面影響。

但此時，我又想起 2020 年 Rust 1.44 版本釋出時，官方部落格說過這麼一句話：「tech is and always will be political」。

當時，正好趕上了明洲白人警察跪殺黑人事件，美國的所有企業現在都在站隊。所以，Rust 官方也必須得表個態：堅決反對美國警察的暴行。當時看上去好像很正常，但我沒有注意到在官方內網上對此已經有了很多討論[27] ，現在回頭再看這件事，感覺稽核團隊離職事件並非偶然。

對於美國文化不太瞭解的我，之前還對稽核團隊存在的重要性嗤之以鼻，現在感覺稽核團隊的存在對於 Rust 這樣深處文化政治複雜的美國是多麼重要。我終於理解 Rust 官方團隊所說這件事的背景相當複雜的原因了。

真心希望 Rust 社群少一些政治、種族等非技術言論和矛盾。Rust 語言是全球的，不是某個國家的。真心希望 Rust 團隊能處理好這件事。對此，我們能做些什麼呢？也許只能祈禱世界和平。

Rust 在各個領域中的應用狀態和趨勢

接下來，我們來盤點一下 2021 年 Rust 在各個領域中應用的狀態和可能的趨勢是什麼。

作業系統

先從作業系統來看起。

Rust for Linux

從 2020 年 6 月，Rust 進入Linux 就開始成為一個話題。Linux 建立者 Linus 在當時的開源峰會和嵌入式Linux 會議上談到了為開源核心尋找未來維護者的問題。

Linus 提到：“核心很無聊，至少大多數人認為它很無聊。許多新技術對很多人來說應該更加有趣。事實證明，很難找到維護者。雖然有很多人編寫程式碼，但是很難找到站在上游對別人程式碼進行 Review 的人選。這不僅僅是來自其他維護者的信任，也來自所有編寫程式碼的人的信任……這只是需要時間的”。

Rust 作為一門天生安全的語言，作為C的備選語言，在幫助核心開發者之間建立彼此的信任，是非常有幫助的。三分之二的 Linux 核心安全漏洞( PDF[28] )來自記憶體安全問題，在 Linux 中引入 Rust 會讓其更加安全，這目前基本已經達成一種共識。

在今年（2021）的開源峰會上， Linus 說道：“我認為C語言是一種偉大的語言，對我來說，C 語言確實是一種在相當低的水平上控制硬體的方法。因此，當我看到C語言程式碼時，我可以非常接近地猜測編譯器的工作。它是如此接近硬體，以至於你可以用它來做任何事情。但是，C語言微妙的型別互動並不總是合乎邏輯的，對幾乎所有人來說都是陷阱。它們很容易被忽視，而在核心中，這並不總是一件好事。Rust 語言是我看到的第一種看起來像是真的可以解決問題的語言。人們現在已經談論Rust在核心中的應用很久了，但它還沒有完成，可能在明年，我們會開始看到一些首次用Rust編寫的無畏的模組，也許會被整合到主線核心中。”

Linus 認為 Linux 之所以如此長青，其中一個重要的基石就是樂趣（Fun），並且樂趣也是他一直追求的東西。當人們討論使用Rust編寫一些Linux核心模組的可能性時，樂趣就出現了。

在剛過去的 2021 年 9 月的 Linux Plumbers 大會上，再一次討論了 Rust 進入 Linux 核心的進展。

Rust for Linux 的主力開發者 Miguel Ojedal 說，Rust 如果進入核心，就應該是一等公民的角色。Linus 則回答，核心社群幾乎肯定會用該語言進行試驗。
Rust 進入核心肯定會有一些維護者需要學習該語言，用來 review Rust 程式碼。Linus 說， Rust 並不難懂，核心社群任何有能力 review patch 的人都應該掌握 Rust 語言到足以 Review 該語言程式碼的程度。
Ojedal 說，目前核心工作還再使用一些 Unstable 的 Rust 特性，導致相容性不夠好，不能確保以後更新的 Rust 編譯器能正常編譯相關程式碼。但是如果 Rust 進入 Linux 核心，就會改變這種情況，對於一些 Unstable Rust 特性，Rust 官方團隊也會考慮讓其穩定。這是一種推動力，遲早會建立一個只使用 Rust 穩定版的核心，到時候相容問題就會消失。
另一位核心開發者 Thomas Gleixner 擔心 Rust 中並沒有正式支援記憶體順序，這可能會有問題。但是另一位從事三十年cpp 併發程式設計的 Linux 核心維護者 Paul McKenney 則寫了一系列文章[29]來探討 Rust 社群該如何就Rust 進入 Linux 核心這件事正確處理記憶體順序模型。對此我也寫了另一篇文章【我讀】Rust 語言應該使用什麼記憶體模型？。
關於 Rust 對 GCC 的支援，其中 rustc_codegen_gcc進展最快，目前已通過了部分的 rustc 測試，rustc_codegen_llvm是目前的主要開發專案，Rust GCC預計在 1~2 年內完成。

這次大會的結論是：

Rust 肯定會在 Linux 核心中進行一次具有時代意義的實驗。
Rust 進入 Linux 核心，對於推動 Rust 進化具有很重要的戰略意義。

2021 年 11 月 11 日，在 Linux 基金會網站上，又放出另一場錄製的網路會議：Rust for Linux：編寫安全抽象和驅動程式[30]，該視訊中 Miguel Ojeda 介紹了 Rust 如何在核心中工作，包括整體基礎設施、編譯模型、文件、測試和編碼指南等。

我對這部分視訊內容做了一個簡要總結：

介紹 Unsafe Rust 和 Safe Rust。
在 Linux 核心中使用 Rust ，採用一個理念：封裝 Unsafe 操作，提供一個安全抽象給核心開發者使用。這個安全抽象位於 https://github.com/Rust-for-L...[31] 的 kernel 模組中。
給出一個簡單的示例來說明如何編寫核心驅動
對比 C 語言示例，給出 Rust 中什麼是 Safety 的行為。
介紹了文件、測試和遵循的編碼準則。

2021.12.6 早上發出了更新的補丁，介紹了在核心中處理 Rust 的初始支援和基礎設施。

這次更新的內容包括：

升級到了最新 Stable 編譯器和 Rust 2021 edition 。因此可以擺脫了 const_fn_transmute，const_panic、const_unreachable_unchecked、core_panic 和try_reserve 這幾個之前未穩定的特性。未穩定特性心願單[32]。
自定義 core 和 alloc。為 alloc 新增了更加模組化的選項，以便禁用一些他們不需要的功能：no_rc 和 no_sync，主要是為上游 Rust 專案新增。
更嚴格的程式碼、文件和新的 lint。
抽象和驅動程式更新。新增了序列鎖、電源管理回撥的抽象，io 記憶體（readX/writeX）、irq 晶片和高階流處理程式，gpio 晶片（包括 irq 晶片）、裝置、amba 裝置和驅動程式以及證照。此外，也改進並簡化了 Ref（refcount_t 支援）物件並用它替換了 Rust 的 Arc 的所有例項。完全地從 alloc crate 中刪除了 Arc 和 Rc。

從現在開始，Rust for linux 團隊將開始定期提交補丁，每兩週左右。

除了來自 Arm、Google 和 Microsoft 的支援外，這次該團隊又收到一封來自紅帽的信：紅帽對 Rust 用於核心的工作也非常感興趣（There is interest in using Rust for kernel work that Red Hat is considering）。

v2 補丁：https://lore.kernel.org/lkml/...[33]
https://www.phoronix.com/scan...[34]
kernel crate 文件[35]

綜合上面我們瞭解到的這些資訊，2022 年，我們很可能會看到 Linux 核心中的實驗性 Rust 程式語言支援成為主流。如果這次實驗成功，那麼就意味著 Rust 正式從 C 語言手裡拿到了時代的交接棒。

Redox + Theseus

Redox 是純 Rust 實現的類似於 MINIX[36] 的微核心設計，它提供了記憶體分配器、檔案系統、顯示管理器、核心實用程式等等，它們共同構成了一個功能性作業系統。

Redox 的發起者雖然在 System76 工作，但實際上 Redox 這個專案並未得到 System76 的贊助。我曾經以為 Redox 屬於 System76 的商業開源專案，但最近才發現，Redox 的花費都是來自於社群贊助。Redox 的主要開支基本都是用於 Redox OS Summer of Code ，招募一些學生，為其完善功能。

Redox 在 2021 年比較重要的一個動態是，另一個 Rust 實現的作業系統 Theseus[37] 宣佈加入 Redox 。

現代 OS 中不同程式會共享很多狀態，這會導致 state spill 的問題，比如，如果 Android 系統服務失敗，“整個使用者空間框架”就會崩潰，影響所有應用程式，甚至影響那些不使用失敗服務的應用程式。

Theseus OS 有許多微小的元件，稱為單元，每個都有明確的界限。每個單元都是一個 Rust crate。然而，更大的創新是他們所謂的“語內（Intralingual）作業系統設計”，他們的意思是使用程式語言機制來實現作業系統，即，“將語義錯誤從執行時錯誤轉變為編譯時錯誤”。這意味著，Theseus 相比於其他 OS 與 Rust 的關係更加緊密。

Theseus OS 故障恢復涉及用新的單元替換損壞的單元。研究人員聲稱，這“允許 Theseus 在面對多個故障子系統時容忍最低系統層中的故障。” 這是一種單元交換技術，也許這就是 Theseus 這個名字的由來，忒修斯之船的故事應該都聽過吧？

嵌入式 OS

Tock OS 2.0

Tock[38] 是一個嵌入式作業系統，設計用於在基於Cortex-M和RISC-V的嵌入式平臺上執行多個併發的、互不信任的應用程式。Tock的設計以保護為中心，既可以防止潛在的惡意應用程式，也可以防止裝置驅動程式。Tock使用兩種機制來保護作業系統的不同元件。首先，核心和裝置驅動程式是用Rust編寫的，Rust是一種提供compile-time記憶體安全、型別安全和嚴格別名的系統程式語言。Tock使用Rust來保護核心（例如排程程式和硬體抽象層）不受特定於平臺的裝置驅動程式的影響，並將裝置驅動程式彼此隔離。其次，Tock使用記憶體保護單元將應用程式彼此和核心隔離開來。

“Google釋出的這個 OpenSK 是跑在 Tock上面的！OpenSK [39]是用Rust編寫的安全金鑰的開源實現，該金鑰同時支援FIDO U2F和FIDO2標準。

今年 Tock OS 的一個動作是，它升級到了 2.0 版本，並且這次升級是一次重大更新，完全是新核心，核心核心 API 被重新設計。

並且對晶片和開發板的支援基本覆蓋的非常全面：RISC-V / ARM CortexM0+ / ARM CortexM7 / Nano RP2040 / Rapsberry Pi Pico/ ESP32-C3-DevKitM-1 等等。

Hubris

Hubris[40] 沒有執行時建立或銷燬任務的操作，沒有動態資源分配，沒有以特權模式執行的驅動程式程式碼，系統中也沒有C程式碼。通過這種構造，消除了許多通常存在於類似系統中的攻擊面。

OXide 公司在今年 OSFF Mini Summit 2021 會議上分享了即將到來的韌體革命[41] 中提到，Rust 將會是即將到來的韌體革命的一部分。所以，他們重新審視嵌入式作業系統並用 Rust 開發了 Hubris。Hubris 目前只支援 Arm Cortex M 平臺。

Hubris vs TockOS ：

Tock 使用動態載入，Hubris是靜態的
Tock 是非常非同步的，Hubris是嚴格同步的
Tock 的驅動程式與核心在同一保護區，Hubris 的驅動程式位於不同的投影域中

其他

新版VxWorks

風河 VxWorks[42] 是一款確定性、基於優先順序的搶佔式實時作業系統，具有超低延遲和最小抖動。其官網在最新版宣佈唯一支援 C ++ 17、Boost、Rust、Python、pandas等開發語言的實時作業系統。

雲原生

Linkerd2

2021 年對於 Linkerd 來說是標誌性的一年。該專案在 Cloud Native Computing Foundation 中畢業了[43]，它代表專案成熟度的最高階別。Linkerd 的採用率在今年飆升，組織範圍廣泛，如Microsoft[44]、S&P Global[45]，以及挪威勞工和福利管理局[46]，以及許多其他機構，都公開採用了 Linkerd。

Linkerd 2.11 在2021年9月釋出[47]，更多元件向 Rust 遷移。Linkerd 之前只有 proxy 部分是 Rust 實現，釋出的2.11.0版本中，Linkerd採用了一個用Rust編寫的新策略控制器元件！它使用 kube-rs 與Kubernetes API進行通訊，並暴露了一個用Tonic實現的 gRPC API。

雖然 Linkerd 在資料面有豐富的Rust經驗，但他們選擇Go作為控制面元件，因為Kubernetes生態系統（以及它的API客戶端等）是如此嚴重地傾向於Go。然而，由於u/clux在kube-rs上的出色工作，現在用Rust實現控制器已經變得可行。這對Linkerd專案來說是一大進步，他們計劃在整個專案中更多地使用Rust。它釋出了多個基準測試，顯示效能和資源使用領先於 Istio 一個數量級[48]；它繼續引領著將 Rust 帶入[49]雲原生領域。他們希望Linkerd的這個新方向將有助於歡迎更多希望增長Rust實踐經驗的貢獻者。

如果對 Linkerd2 的 2022 年路線圖感興趣可以點選這裡[50]。

Deislabs[51] 的專案

Akri

Akri [52] 是雲原生計算基金會 (CNCF)的一個沙盒專案，用於為 Kubernetes 提供邊緣計算解決方案。Akri 旨在成為在邊緣的 Kubernetes 叢集上使用物聯網裝置的標準方式，這就是為什麼 Akri 在希臘語中不僅意味著“邊緣”，而且還代表 Kubernetes 資源介面。

Krustlet

Krustlet[53] 是一種 kubelet[54] 實現，使使用者能夠在同一個 Kubernetes 叢集中執行 WebAssembly 和傳統容器工作負載。

在 2021 年，Krustlet 和 krator[55] 專案（Kubernetes Rust 狀態機操作框架）一起成為了 CNCF 的沙盒專案，到目前為止，已經發布了 1.0-alpha.1 版本，1.0 正式版本即將釋出。

那麼，這個 1.0究竟意味著什麼？它意味著穩定性和向後相容性保證。人們就可以開始用它構建一些真正的產品了。隨著 WebAssembly 和 WASI 的成熟，後面還會新增更多功能。

WebAssembly ServerSide 與邊緣計算

Lucet

在 Fastly 2021 回顧[56] 文章中提到：

“Daily request traffic for Compute@Edge experienced explosive growth in 2021, skyrocketing over 31,000% from January’s daily traffic. Customer usage is on pace to reach 2 trillion total requests across 2021, with a target to reach 50 trillion requests[57] by the end of 2022.2021年，Compute@Edge的每日請求流量經歷了爆炸性的增長，比1月份的每日流量暴漲了31,000%以上。客戶使用量有望在2021年達到2萬億次總請求，目標是在2022年底達到50萬億次。

而這個 Compute@朝夕相處58 是 Fastly 的邊緣計算平臺，它能夠執行你在自己的系統上編譯並上傳到 Fastly 的自定義二進位制檔案。通過將程式碼編譯到WebAssembly[59]來提供安全性和可移植性，他們使用 Lucet[60] 在邊緣執行它，Lucet 是由 Fastly 建立的開源 WebAssembly 執行時。而 Lucet 是基於位元組碼聯盟的 wasmtime[61] WebAssembly 執行時來實現的。

其他

在 WebAssembly Serverside 領域，還有很多極具創新的產品：

WasmEdge，是用於邊緣計算和軟體定義車輛的輕量級、快速和任務關鍵型程式碼 runtime 。目標是大幅降低複雜性並提高開發速度。它是目前市場上最快的 Wasm 虛擬機器，由 Cpp 開發，但是現在正在開發 Rust SDK，會全面擁抱 Rust。
WasmCloud[62]，是一個基於 WebAssembly 的分散式計算平臺，目前也是 CNCF 沙盒專案。比較有創新的地方在於，它制定了一個 waPC 標準，用於 Guest 和 Host 的安全過程呼叫，來解決當前 WASI 等特性不完善的問題。

位元組跳動的飛書、安全部門、基礎設施部門都已經用上了 Rust ，並且還開源了一些基礎庫[63]。

其中比較出色的可用於雲原生專案的有：

monoio[64]，是一個基於 io-uring 的 Thread-per-core 模型的非同步 Runtime，詳細介紹參見:《Rust 非同步執行時的設計與實現》[65]
keyhouse[66] ，位元組內部使用的金鑰管理系統已經在github上開源了，支援加解密和敏感配置管理。目前位元組內部很多業務都基於該系統進行開發。

物聯網（IoT）

*Rust 嵌入式工作組進展**

樹莓派2021釋出首款RP2040微控制器中有兩個Cortex M0核心。這讓工作組的成員開始思考，在多核微控制器下該如何提供安全性，由此有了 rp-rs 組織。
Espressif （樂鑫）正式僱傭mabez 針對eso晶片開發Rust支援：esp-rs
其他平臺也逐漸開始支援Rust，包括：Atmel ARM SAM-D和SAM-E、Atmel AVR、NXP ARM iMX. RT微控制器、ARM nRF51、52和9160藍芽/LTE裝置、RISC-V、樹莓派、STM32等。
嵌入式Rust生態得到長足發展：
嵌入式併發框架RTIC[67]已經1.0
嵌入式非同步框架Embassy[68]正在大力開發且支援STM32，nRF和RP2040平臺，並且還深深影響著Rust非同步的改進
嵌入式開發和除錯工具Knurling[69]又釋出了新的探針工具
嵌入式 TCP/IP棧smoltcp[70] 釋出了新版本
嵌入式圖形庫embedded-graphics[71] 釋出了新版本
新的嵌入式實時OS Hubirs 開源。
嵌入式工作組自身維護的專案在這一年也是大力開發和維護中。

更多參見: https://blog.rust-embedded.or...[72] 。

總的來說，Rust 在嵌入式領域越來越成熟了。

樂鑫晶片(Espressif) esp-rs 進展

2021 年，樂鑫公司宣佈僱傭 mabez 來全職從事 Rust 對 ESP32 的支援，對應GitHub 開源組織是 esp-rs[73]。這意味著，Rust 將全面進入 esp32 領域。

截止年底，mabez 完成的工作可以在其部落格看到，總的來說目前進度為：

esp-rs book[74]
probe-rs 對 esp32c3 的支援現在比較完善了
espflash 達到了 1.0
引入 esp32-hal[75]
其他，還有很多

更多更新可以參見 Rust on Espressif chips - 10-01-2022[76] 。不得不說，樂鑫是一家很有遠見的公司。

趨勢

ARM 是迄今為止在物聯網邊緣使用的晶片組和感測器等嵌入式裝置的領先製造商，今年已經加入了 Rust 基金會。

Rust 完全有能力在嵌入式計算等更高階別的物聯網領域完成特定任務，例如邊緣輕量級計算和後端服務的實現，並同時可以在一定程度上滿足這類物聯網基礎設施的功能安全需求。

由於其生態系統與物聯網相關的部分，仍在不斷髮展，甚至缺乏一些重要的基礎，而且遠非穩定。但從好的方面來說，我們看到像 Drogue、Ferrous Systems 和其他獨立的幾家公司正在努力推動 Rust 進入物聯網領域而對至關重要的基礎正在進行積極的開發，併為 Rust 帶來更光明的未來。

遊戲

GPU 圖形渲染值得關注的專案

rust-gpu

rust-gpu[77] 是 embark studios 開源的一個專案，致力於讓 Rust 成為圖形渲染領域的第一類語言。目前正聯合 Traverse research 公司一起構建rust-gpu。

“Embark 是和韓國遊戲公司 Nexon （《冒險島》《跑跑卡丁車》）合開的。Embark CEO 是前EA 首席設計官 Patrick ，曾是《戰地》系列開發商 DICE 的 CEO。Embark 也是 Rust 遊戲工作組的成員之一，該公司也贊助了很多 Rust 生態開源專案的作者。Traverse research 公司位於荷蘭 Breda 中心區，願景是讓Breda 成為遊戲開發強鎮。該團隊的核心成員在圖形學領域造詣很強。

rust-gpu 主要是針對圖形渲染引擎，希望可以把 Rust 引入為一種著色語言。通過 rustc 後端編譯到 spir-v （著色器的二進位制中間語言）來達成這個目標。目前該領域常用的是 GLSL/HLASL ，但它們並未隨著遊戲行業發展提供處理大型程式碼庫的機制，所以在這個領域急需一門優秀的著色語言，而 embark 的人們認為 Rust 就是最佳選擇，所以他們做了這項工作。

embark 還基於 rust-gpu 開源了一個實驗性的全域性光照渲染引擎 kajiya[78]。

Rust-CUDA

Rust-CUDA[79] 則是一個旨在使 Rust 成為使用 CUDA 工具包進行極快 GPU 計算的 1 級（tier-1）語言的專案。該團隊希望通過這個專案，可以推動 Rust GPU 計算行業向前發展，並使 Rust 成為此類任務的優秀語言。Rust 提供了很多好處，例如高效利用每個核心的效能優勢、出色的模組/crate系統、用 unsafe分隔 CPU/GPU 程式碼的不安全區域、為底層 CUDA 庫構建高階包裝器等。

遊戲引擎中的佼佼者

Bevy

Bevy[80] 是一個基於 Rust 實現的資料驅動遊戲引擎。相比於 Rust 實現的其他遊戲引擎，比如 Amethyst， Bevy 屬於後來著居上。Bevy 在 API 設計方面獨具匠心，充分利用 Rust 語言特點，讓開發者上手非常簡單方便。得力於其 Plugin 機制，目前 Bevy 已經逐漸形成自己的生態，逐步湧現出很多基於 Bevy 的 Plugin 。

Bevy 作為開源專案，在 GitHub 上接受的贊助現在基本已經達成了每月 6000 美刀的目標。雖然目前 Bevy 只發布了 0.6 版本，但是其生態在逐步建立，並且受到很多人的歡迎和期許。

Bevy 0.6 版本中有大量改進、錯誤修復和質量提升，這裡羅列一部分：

一個全新的現代渲染器，更漂亮、更快、更易於擴充套件
原生 WebGL2 支援。您可以通過在瀏覽器中執行 Bevy 示例[81]來測試它！[82]
更強大的著色器：前處理器、匯入、WGSL 支援
Bevy ECS 人體工程學和效能改進。沒有了.system()！

更多參見Bevy 0.6 介紹[83] 。

Fyrox(Rg3d)

Fyrox(rg3d)[84] 是另一款 Rust 實現的遊戲引擎，支援 3D 和 2D ，之前專案名為 rg3d，現在已經改名為 Fyrox[85] 。

該遊戲引擎雖然沒有 bevy 那樣受人關注，但也在高速發展中，目前已經發布了 0.24 版本。簡單來說的變化：

2d 支援。從一開始，引擎只專注於 3D 遊戲，但在 rg3d 0.23 中情況發生了一些變化，新增了一個簡單的 2D 場景版本。
增加了開發指南
物理整合
引入了聲音引擎 rg3d-sound

詳細參見 rg3d 0.24 功能亮點[86]

Amethyst 新的開始

Amethyst 引擎宣佈停止開發[87]，遊戲引擎的火炬傳遞給了 Bevy，未來 Amethyst 基金會還會在遊戲領域創造價值，但不侷限於遊戲引擎。

為什麼會這樣？

Amethyst 從自上而下的BDFL模式轉為扁平的對等模式之後，一直沒有找到自己的立足點。團隊內部對 Amethyst 的目標缺乏統一看法。
Bevy 引擎發展的不錯，將會把 Amethyst 引擎的火炬傳遞下去。

Amethyst 引擎做的好的一面：建立了一個先進的、由ECS驅動的遊戲引擎，數以百計的Rust遊戲開發愛好者通過Amethyst相互聯絡，並建立了持久的友誼。

“BDFL: BDFL 是英文「Benevolent Dictator For Life」的縮寫。中文翻譯為「仁慈的終身獨裁者」。在此架構下，有一個人（通常是專案的最初的作者，或者是社群選舉的一個人）擁有專案中所有最後的決定。較小的專案可能預設就是 BDFL 結構，因為此類專案一般就是一到兩位維護者。若是公司組織的專案也極有可能會採用 BDFL 結構，以便掌握專案的決策權。

Amethyst 的未來

Amethyst 早就成立了基金會，雖然遊戲引擎停止了開發，但是 Amethyst 基金會還會在遊戲領域繼續投入。但未來將不再單一地專注於製作任何特定的遊戲引擎。

接下來可能會幫助 Rust 遊戲開發新人進入這個領域而做一些努力，比如推廣、協調、教育、社群建設等。並且現在 Amethyst 團隊做的一些都將和引擎無關，比如 Distill, specs, Legion, Laminar 等。

注意：Amethyst 只是停止了遊戲引擎的開發，但他們將邁向更廣泛的 Rust 遊戲開發領域去做更具價值的事。

資料處理

Databend 資料雲

Databend[88] 旨在成為一個開源的彈性和可靠的雲倉庫，它提供了極快的查詢，並結合了雲的彈性、簡單性和低成本，旨在使資料雲變得簡單。

Databend 受 ClickHouse 啟發，計算模型基於 apache-arrow。Databend實現了彈性的完全面向雲架構的設計，它強調狀態和計算的分離。相比傳統數倉，使用者使用Databend會獲得更低成本、更易用、按量付費的體驗。Databend會向著Serverless方向迭代。Serverless意味著把資源的排程做到更加精細化，雲資料庫的計算結點可以和一個函式一樣，使用的時候拉起，使用完畢後銷燬，只需要用使用付費，資源排程會非常精確。

資料流處理

Tremor

Tremor[89] 是一個事件處理系統。它最初是為了替代 Logstash 或 Telegraf 等軟體而設計的。然而，通過支援更復雜的工作流（例如聚合、彙總、ETL 語言和查詢語言），tremor 已經超出了這個單一用例的範圍。

Tremor 每年 365 天 24x7 執行，並使用 Rust 程式語言實現。

“深挖了一下 tremor-runtime 專案背後的公司，原來是 Wayfair 。Wayfair 是美國最大的傢俱電商，2017 年市值就達58億美元，前身是早在2002年就成立的CNSStores。亞馬遜都吃不下它。Tremor 應該是 Wayfair 公司旗下的開源專案，已經進入 CNCF 。2021 年九月份還召開了一次小型的線上的 Tremor Conf[90]2020年3月份的一次分享：Rust 如何為 Wayfair 省掉數千個核心和TB級的記憶體的成本：2020-03-31-RustAndTellBerlin-functions[91]從2018年開始， tremor 就是跑在了 wayfair生產環境中，每天處理10兆位元組的資料，或每分鐘100億條訊息，每秒1000萬個指標。tremor 降低了成本，減少了複雜性，鞏固和簡化了操作環境，以激發SRE的樂趣，減少NOC的工作量，並降低運營成本。

實時分析的流式資料庫 Materialize

Materialize[92] 是一個提供增量檢視更新的反應式資料庫，它幫助開發人員使用標準 SQL 輕鬆構建流資料。在無需複雜的資料管道的情況下，只須用標準SQL檢視描述計算，然後將 Materialize 連線到資料流，就能實現增量計算。底層的差異資料流[93]引擎（相關論文 Online Analysis of Distributed Dataflows with Timely Dataflow[94]）能夠執行增量計算，以最小的延遲提供一致且正確的輸出。與傳統資料庫不同，定義 Materialize 的檢視沒有任何限制，並且計算是實時執行的。

該公司已經進入 B 輪，融資 4000萬美刀。

其他

fluvio[95] : 是一個開源資料流平臺，可聚合、關聯並將可程式設計智慧應用於動態資料。Fluvio 由 Rust 提供支援，在雲原生架構上提供低延遲、高效能的可程式設計流。
vector[96]: 用於構建可觀察性管道的輕量級、超快速工具。