三萬字｜2021 年 Rust 行業調研報告

文前

Rust 語言是一門通用系統級程式語言，無GC且能保證記憶體安全、併發安全和高效能而著稱。自2008年開始由 Graydon Hoare 私人研發，2009年得到 Mozilla 贊助，2010年首次釋出 0.1.0 版本，用於Servo 引擎的研發，於 2015年5月15號釋出 1.0 版本。

自發布以來，截止到 2021 年的今天，經歷六年的發展，Rust 得到穩步上升，已逐漸趨於成熟穩定。

至 2016 年開始，截止到 2021年，Rust 連續五年成為 StackOverflow 語言榜上最受歡迎的語言[1]。

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

那 Rust 語言到底有何魅力，能讓廣大開發者和巨頭公司這麼感興趣呢？

本文從 Rust 語言自身特性 和 Rust 行業應用盤點兩個方面的社群調研來嘗試來解答這個問題，希望通過這些簡單但關鍵的資料來對 Rust 在當前各大領域應用有個比較全面且直觀的印象，供想選擇 Rust 的公司參考。

註明：本文中所羅列資料均來源網際網路公開內容。

認識 Rust 語言

程式語言設計在兩個看似不可調和的願望之間長期存在著矛盾對立。

• 安全 ( safe )。我們想要強類型系統來靜態地消除大量錯誤。我們要自動記憶體管理。我們想要資料封裝， 這樣我們就可以對私有變數執行不變的物件的表示形式，並確保它們將不會被不受信任的程式碼破壞。
• 控制 (control )。至少對於 Web瀏覽器，作業系統，或遊戲引擎這樣的 系統程式設計 (system programming) 程式，約束它們效能或資源是一個重要的問題，我們想了解資料的位元組級表示。我們想要用底層語言 (low-level programming) 的程式設計技術優化我們程式的時間和空間的使用。我們希望在需要時使用 裸機 。

然而，按照傳統的看法，魚和熊掌不能兼得。Java 之類的語言使我們極大的安全保證，但代價是犧牲對底層的控制。結果，對於許多系統程式設計應用程式，唯一現實的選擇是使用一種像 C 或 C++ 提供細粒度的語言控制資源管理。但是，獲得這種控制需要很高的成本。例如，微軟最近報告說，他們修復的 70％ 安全漏洞都歸因於記憶體安全違規行為 33[2]，並且都是能被強類型系統排除的問題。同樣，Mozilla 報告指出，絕大多數關鍵 他們在Firefox中發現的錯誤是記憶體有關的16 [3]。

如果可以以某種方式兩全其美: 安全系統程式設計的同時對底層有控制權，豈不美哉。因此，Rust 語言應運而生。

官方網如此介紹 Rust  : 一門賦予每個人 構建可靠且高效軟體能力的語言。

Rust 語言有三大優勢值得大家關注：

1. 高效能。Rust 速度驚人且記憶體利用率極高。由於沒有運行時和垃圾回收，它能夠勝任對效能要求特別高的服務，可以在嵌入式裝置上運行，還能輕鬆和其他語言整合。
2. 可靠性。Rust 豐富的類型系統和所有權模型保證了記憶體安全和執行緒安全，讓您在編譯期就能夠消除各種各樣的錯誤。
3. 生產力。Rust 擁有出色的文件、友好的編譯器和清晰的錯誤提示資訊， 還集成了一流的工具——包管理器和構建工具， 智慧地自動補全和類型檢驗的多編輯器支援， 以及自動格式化程式碼等等。

Rust 足夠底層，如果有必要，它可以像 C 一樣進行優化，以實現最高效能。

抽象層次越高，記憶體管理越方便，可用庫越豐富，Rust 程式程式碼就越多，做的事情越多，但如果不進行控制，可能導致程式膨脹。

然而，Rust 程式的優化也很不錯，有時候比 C 語言更好，C 語言適合在逐個位元組逐個指針的級別上編寫最小的程式碼，而 Rust 具有強大的功能，能夠有效地將多個函數甚至整個庫組合在一起。

但是，最大的潛力是可以無畏（fearless）地並行化大多數 Rust 程式碼，即使等價的 C 程式碼並行化的風險非常高。在這方面，Rust 語言是比 C 語言更為成熟的語言。

Rust 語言也支援高併發零成本的非同步程式設計，Rust 語言應該是首個支援非同步程式設計的系統級語言。

媲美 C / Cpp 的高效能

Rust vs C

Rust vs Cpp

Rust vs Go

用 Rust 編寫的程式的運行時速度和記憶體使用量應該和用 C 編寫的程式差不多，但這兩種語言的總體程式設計風格不同，很難去概括它們的效能。

總的來說：

1. 抽象是一把雙刃劍。Rust 語言抽象程度比 C 語言更高，抽象會隱藏一些不是那麼優化的程式碼，這意味著，預設實現的 Rust 程式碼效能不是最好的。所以，你的 Rust 程式碼必須經過優化才能達到媲美 C 的效能。Unsafe Rust 就是高效能出口。
2. Rust 預設執行緒安全，消除資料競爭，讓多執行緒併發程式設計更具實用價值。
3. Rust  在有些方面確實比 C 快。理論上，C 語言什麼都可以做。但在實踐中，C 抽象能力比較低，不那麼現代化，開發效率比較低。只要開發者有無限時間和精力，就可以讓 C 語言在這些方面比 Rust 更快。

因為 C 語言足以代表高效能，下面就分別談一下 C 和 Rust 的異同。如果你熟悉 C/Cpp，也可以根據此對比來評估 Cpp 和 Rust。

Rust 和 C 都是硬體直接抽象

Rust 和 C 都是直接對硬體的抽象，都可看作一種「可移植彙編程式」。

Rust 和 C 都能控制資料結構的記憶體佈局、整數大小、棧與堆記憶體分配、指針間接定址等，並且一般都能翻譯成可理解的機器程式碼，編譯器很少插入 "魔法"。

即便 Rust 比 C 有更高層次的結構，如迭代器、特質（trait）和智慧指針，它們也被設計為可預測地優化為簡單的機器程式碼（又稱 "零成本抽象"）。

Rust的類型的記憶體佈局很簡單，例如，可增長的字元串String 和 Vec<T> 正好是{byte*, capacity, length}。Rust沒有任何像 Cpp裡的 移動 或 複製建構函式 這樣的概念，所以物件的傳遞保證不會比傳遞指針或 memcpy 更復雜。

Rust 借用檢查只是編譯器對程式碼中引用的靜態分析。生命週期（lifetime）資訊早就在 中級中間語言（MIR） 生成前完全抽離了。

Rust 中不使用傳統的異常處理，而是使用基於返回值的錯誤處理。但你也可以使用 恐慌（Panic）來處理像 Cpp 中那樣的異常行為。它可以在編譯時被禁用（panic = abort），但即便如此，Rust 也不喜歡 與 Cpp異常 或 longjmp 混在一起。

同樣的 LLVM 後端

Rust與LLVM有很好的整合，所以它支援連結時間優化，包括ThinLTO，甚至是跨越C/C++/Rust語言邊界的內聯。也有按配置優化（Profile-guided Optimization，PGO）的支援。儘管 rustc 比 clang 生成的LLVM IR更加冗長，但優化器仍然能夠很好地處理它。

C 語言用 GCC 編譯比用 LLVM 更快，現在 Rust 社群也有人在開發 GCC 的 Rust 前端。

理論上，因為 Rust 有比C 更嚴格的不可變和別名規則，應該比 C 語言有更好的效能優化，但實際上並沒有起到這樣的效果。目前在LLVM中，超越 C語言的優化是一項正在進行的工作，所以Rust仍然沒有達到其全部潛力。

都允許手工優化，但有一些小例外

Rust 的程式碼足夠底層和可預測，可以通過手工調整它的優化到什麼樣的彙編程式碼。

Rust 支援 SIMD ，對內聯和呼叫約定有很好的控制。

Rust 和 C 語言足夠相似，C 語言的一些分析工具通常可以用於 Rust 。

總的來說，如果效能絕對關鍵，並且需要手工優化壓榨最後一點效能，那麼優化 Rus t 與 優化 C 語言並沒有什麼不同。

但是在一些比較底層的特性，Rust 沒有特別好的替代方法。

• goto。Rust 中沒有提供goto，不過你可以使用迴圈的 break 標籤來代替。C 語言中一般使用 goto 來清理記憶體，但是 Rust 因為有確定性析構功能，所以不需要 goto。然而有一個 非標準的 goto 擴展，對效能優化比較有用。
• 棧記憶體分配alloca和C99可變長度陣列，可以節省記憶體空間，減少記憶體分配次數。但這些即使在 C 語言中也是有爭議的，所以Rust遠離了它們。

Rust 相比 C 語言的一些開銷

如果沒有經過手工優化，Rust 因為其抽象表達也會有一些開銷。

• Rust缺乏隱式類型轉換和只用usize的索引，這導致開發者只能使用這種類型，哪怕只需要更小的資料類型。64位平臺上用usize做索引更容易優化，而不需要擔心未定義行為，但多餘的bit位可能會給寄存器和記憶體帶來更大的壓力。而在 C 中，你可以選擇 32位類型。
• Rust 中的字元串，總是會攜帶指針和長度。但是很多 C 程式碼中的函數只接收指針而不管大小。
• 像 for i in 0...len {arr[i]} 這樣的迭代，效能取決於 LLVM 優化器能否證明長度匹配。有時候，它不能，並且邊界檢查也會抑制自動向量化。
• C 語言比較自由，對於記憶體有很多「聰明」的使用技巧，但在 Rust 裡就沒這麼自由了。但Rust仍然給了記憶體分配很多控制權，並且可以做一些基本的事情，比如記憶體池、將多個分配合併為一個、預分配空間等等。
• 在不熟悉 Rust 借用檢查的情況下，可能會用 Clone 來逃避使用引用。
• Rust 的標準庫中 I/O 是不帶快取的，所以需要使用 BufWriter 來包裝。這就是為什麼有些人說 Rust 寫的程式碼還不如 Python 快的原因，因為 99% 的時間都用在 I/O上了。

可執行檔案大小

每個作業系統都有一些內建的標準C庫，其中有大約30MB的程式碼。C 語言的執行檔案，可以「免費」使用這些庫。

一個小的 "Hello World " 級 C 可執行檔案實際上不能列印任何東西，它只調用作業系統提供的printf。

而 Rust 則不可以，Rust可執行檔案會捆綁自己的標準庫（300KB或更多）。幸運的是，這只是一次性的開銷，可以減少。

對於嵌入式開發，可以關閉標準庫，使用 "no-std"，Rust將生成 "裸 "程式碼。

在每個函數的基礎上，Rust程式碼的大小與C差不多，但有一個 "泛型膨脹 "的問題。泛型函數為它們所使用的每一種類型都有優化的版本，所以有可能出現同一個函數有8個版本的情況，cargo-bloat[4] 庫有助於發現這些問題。

在Rust中使用依賴關係是非常容易的。與 JS/npm 類似，現在推薦使用小型且單用途的包，但它們確實在不斷增加。cargo-tree 命令對於刪減它們非常有用。

Rust 略勝 C  的一些地方

1. 為了隱藏實現細節，C 庫經常返回不透明的資料結構指針，並確保結構的每個例項只有一個副本。它會消耗堆分配和指針間接定址的成本。Rust 內建的隱私、單一所有權規則和編碼慣例允許庫暴露其物件，而不需要間接性，這樣，呼叫者可以決定將其放入堆（heap）上還是棧（stack）中。可以主動或徹底地優化棧上的物件。
2. 預設情況下，Rust 可以將來自標準庫、依賴項和其他編譯單元的函數內聯。
3. Rust 會對結構體欄位進行重排，以優化記憶體佈局。
4. 字元串攜帶大小資訊，使得長度檢查速度很快。並允許就地生成子串。
5. 與 C++ 模板類似，Rust 中泛型函數會單態化，生成不同類型的副本，因此像 sort 這樣的函數和 HashMap 這樣的容器總是針對相應的類型進行優化。對於 C 語言，則必須在修改宏或者處理void*和運行時變數大小的效率較低的函數之間做出選擇。
6. Rust的迭代器可以組合成鏈狀，作為一個單元一起被優化。因此，你可以呼叫it.buy().use().break().change().mail().upgrade()，而不是對同一個快取區多次寫入的一系列呼叫。
7. 同樣，通過 Read 和 Write 介面，接收一些未快取的流資料，在流中執行 CRC 校驗，然後將其轉碼、壓縮，再寫入網路中，所有這些都可以在一次呼叫中完成。雖然 C 語言中應該也可以做到，但它沒有泛型和特質（trait），將很難做到。
8. Rust 標準庫中內建高質量的容器和優化過的資料結構，比 C 使用起來更方便。
9. Rust的 serde 是世界上最快的JSON解析器之一，使用體驗非常棒。

Rust 比 C 明顯優越的地方

主要是兩點：

1. Rust 消除資料競爭，天生執行緒安全，解放多執行緒生產力，是 Rust 明顯比 C / Cpp  等語言優越的地方。
2. Rust 語言支援非同步高併發程式設計。
3. Rust 支援 安全的編譯期計算。

執行緒安全

即使是在第三方庫中，Rust 也會強制實現所有程式碼和資料的執行緒安全，哪怕那些程式碼的作者沒有注意執行緒安全。一切都遵循一個特定的執行緒安全保證，或者不允許跨執行緒使用。當你編寫的程式碼不符合執行緒安全時，編譯器會準確地指出不安全之處。

Rust 生態中已經有了很多庫，如資料並行、執行緒池、佇列、任務、無鎖資料結構等。有了這類元件的幫助，再加上類型系統強大的安全網，完全可以很輕鬆地實現併發/並行化 Rust 程式。有些情況下，用 par_iter 代替 iter 是可以的，只要能夠進行編譯，就可以正常工作！這並不總是線性加速（ 阿姆達爾定律（Amdahl's law）很殘酷），但往往是相對較少的工作就能加速 2~3 倍。

延伸：阿姆達爾定律，一個電腦科學界的經驗法則，因 Gene Amdahl 而得名。它代表了處理器平行計算之後效率提升的能力。

在記錄執行緒安全方面，Rust 和 C 有一個有趣的不同。

Rust 有一個術語表用於描述執行緒安全的特定方面，如 Send 和 Sync、guards 和 cell。

對於 C 庫，沒有這樣的說法：「可以在一個執行緒上分配它，在另一個執行緒上釋放它，但不能同時從兩個執行緒中使用它」。

根據資料類型，Rust 描述了執行緒安全性，它可以泛化到所有使用它們的函數。

對於 C 語言來說，執行緒安全只涉及單個函數和配置標誌。

Rust 的保證通常是在編譯時提供的，至少是無條件的。

對於 C 語言，常見的是「僅當 turboblub 選項設定為 7 時，這才是執行緒安全的」。

非同步併發

Rust 語言支援 async/await非同步程式設計模型。

該程式設計模型，基於一個叫做 Future 的概念，，在 JavaScript 中也叫做 Promise。Future 表示一個尚未得出的值，你可以在它被解決（resolved）以得出那個值之前對它進行各種操作。在許多語言中，對 Future 所做的工作並不多，這種實現支援很多特性比如組合器（Combinator），尤其是能在此基礎上實現更符合人體工程學的 async/await 語法。

Future 可以表示各種各樣的東西，尤其適用於表示非同步 I/O ：當你發起一次網路請求時，你將立即獲得一個 Future 物件，而一旦網路請求完成，它將返回任何響應可能包含的值；你也可以表示諸如「超時」之類的東西，「超時」其實就是一個在過了特定時間後被解決的 Future ；甚至不屬於 I/O 的工作或者需要放到某個執行緒池中運行的CPU密集型的工作，也可以通過一個 Future 來表示，這個 Future 將會線上程池完成工作後被解決。

Future 存在的問題 是它在大多數語言中的表示方式是這種基於回撥的方法，使用這種方式時，你可以指定在 Future 被解決之後運行什麼回撥函數。也就是說， Future 負責弄清楚什麼時候被解決，無論你的回撥是什麼，它都會運行；而所有的不便也都建立在此模型上，它非常難用，因為已經有很多開發者進行了大量的嘗試，發現他們不得不寫很多分配性的程式碼以及使用動態派發；實際上，你嘗試排程的每個回撥都必須獲得自己獨立的儲存空間，例如 crate 物件、堆記憶體分配，這些分配以及動態派發無處不在。這種方法沒有滿足零成本抽象的第二個原則，如果你要使用它，它將比你自己寫要慢很多，那你為什麼還要用它。

Rust 中的方案有所不同。不是由 Future 來排程回撥函數，而是由一個被稱為執行器（executor）的元件去輪詢 Future。而 Future 可能返回「尚未準備就緒（Pending）」，也可能被解決就返回「已就緒（Ready）」。該模型有很多優點。其中一個優點是，你可以非常容易地取消 Future ，因為取消 Future 只需要停止持有 Future。而如果採用基於回撥的方法，要通過排程來取消並使其停止就沒這麼容易了。

同時它還能夠使我們在程式的不同部分之間建立真正清晰的抽象邊界，大多數其他 Future 庫都帶有事件迴圈（event loop），這也是排程 你的Future 執行 I/O 的方法，但實際上你對此沒有任何控制權。

而在 Rust 中，各元件之間的邊界非常整潔，執行器（executor）負責排程你的 Future ，反應器（reactor）處理所有的 I/O ，然後是你的實際程式碼。因此終端使用者可以自行決定使用什麼執行器，使用他們想使用的反應器，從而獲得更強的控制力，這在系統程式語言中真的很重要。

而此模型最重要的真正優勢在於，它使我們能夠以一種真正零成本的完美方式實現這種狀態機式的 Future 。也就是當你編寫的 Future 程式碼被編譯成實際的本地（native）程式碼時，它就像一個狀態機；在該狀態機中，每次 I/O 的暫停點都有一個變體（variant），而每個變體都儲存了恢復執行所需的狀態。

而這種 Future 抽象的真正有用之處在於，我們可以在其之上構建其他 API 。可以通過將這些組合器方法應用於 Future 來構建狀態機，它們的工作方式類似於迭代器（Iterator）的介面卡（如 filter、map）。但是這種方式是有一些缺點的，尤其是諸如巢狀回撥之類，可讀性非常差。所以才需要實現 async / await非同步語法。

目前 Rust 生態中，已經有了成熟的 tokio[5] 運行時生態，支援 epoll 等非同步 I/O。如果你想用 io_uring ，也可以使用 Glommio[6] ，或者等待 tokio 對 io_uring 的支援。甚至，你可以使用 smol 運行時提供的 async_executor[7] 和 async-io[8] 來構建你自己的運行時。

編譯期計算

Rust 可以支援類似於 Cpp 那樣的 編譯期常量求值。這一點是明顯比C優越的。

雖然目前功能還不如 Cpp 那樣強大，但還在不斷的維護中。

為什麼 Rust 中支援 編譯期計算這麼謹慎呢？因為Rust 編譯期求值是必須要保證安全的，所以有很多考慮。Rust 編譯期求值不像 Cpp 那樣自由且容易濫用。

可靠性

2020 年 6月份，來自3所大學的5位學者在ACM SIGPLAN國際會議（PLDI'20）上發表了一篇研究成果，針對近幾年使用Rust語言的開源項目中的安全缺陷進行了全面的調查。這項研究調查了5個使用Rust語言開發的軟體系統，5個被廣泛使用的Rust庫，以及兩個漏洞資料庫。調查總共涉及了850處unsafe程式碼使用、70個記憶體安全缺陷、100個執行緒安全缺陷。

在調查中，研究員不光查看了所有漏洞資料庫中報告的缺陷和軟體公開報告的缺陷，還查看了所有開源軟體程式碼倉庫中的提交記錄。通過人工的分析，他們界定出提交所修復的BUG類型，並將其歸類到相應的記憶體安全/執行緒安全問題中。所有被調查過的問題都被整理到了公開的Git倉庫中：https://github.com/system-pclub/rust-study[9]

調查結果說明：

1. Rust語言的safe程式碼對於空間和時間記憶體安全問題的檢查非常有效，所有穩定版本中出現的記憶體安全問題都和unsafe程式碼有關。

2. 雖然記憶體安全問題都和unsafe程式碼有關，但大量的問題同時也和safe程式碼有關。有些問題甚至源於safe程式碼的編碼錯誤，而不是unsafe程式碼。

3. 執行緒安全問題，無論阻塞還是非阻塞，都可以在safe程式碼中發生，即使程式碼完全符合Rust語言的規則。

4. 大量問題的產生是由於編碼人員沒有正確理解Rust語言的生命週期規則導致的。

5. 有必要針對Rust語言中的典型問題，建立新的缺陷檢測工具。

那麼這份調查報告背後 Rust 的安全性是如何保證的呢？Unsafe  Rust 又是為什麼 Unsafe 呢？

所有權：Rust 語言記憶體安全機制

Rust 的設計深深地吸取了關於安全系統程式設計的學術研究的精髓。特別是，與其他主流語言相比，Rust 設計的最大特色在於採用了所有權類型系統（在學術文獻中通常稱為仿射或子結構類型系統36[10]）。

所有權機制，就是Rust 語言藉助類型系統，承載其「記憶體安全」的思想，表達出來的安全程式設計語義和模型。

所有權機制要解決的記憶體不安全問題包括：

1. 引用空指針。

2. 使用未初始化記憶體。

3. 釋放後使用，也就是使用懸垂指針。

4. 緩衝區溢位，比如陣列越界。

5. 非法釋放已經釋放過的指針或未分配的指針，也就是重複釋放。

注意，記憶體洩露不屬於記憶體安全問題範疇，所以 Rust 也不解決記憶體洩露問題。

為了保證記憶體安全，Rust 語言建立了嚴格的安全記憶體管理模型：

• 所有權系統。每個被分配的記憶體都有一個獨佔其所有權的指針。只有當該指針被銷燬時，其對應的記憶體才能隨之被釋放。
• 借用和生命週期。每個變數都有其生命週期，一旦超出生命週期，變數就會被自動釋放。如果是借用，則可以通過標記生命週期參數供編譯器檢查的方式，防止出現懸垂指針，也就是釋放後使用的情況。

其中所有權系統還包括了從現代 C++ 那裡借鑑的 RAII 機制，這是 Rust 無 GC 但是可以安全管理記憶體的基石。

建立了安全記憶體管理模型之後，再用類型系統表達出來即可。Rust 從 Haskell 的類型系統那裡借鑑了以下特性：

• 沒有空指針
• 預設不可變
• 表示式
• 高階函數
• 代數資料類型
• 模式匹配
• 泛型
• trait 和關聯類型
• 本地類型推導

為了實現記憶體安全，Rust 還具備以下獨有的特性：

• 仿射類型（Affine Type），該類型用來表達 Rust 所有權中的 Move 語義。
• 借用、生命週期。

藉助類型系統的強大，Rust 編譯器可以在編譯期對類型進行檢查，看其是否滿足安全記憶體模型，在編譯期就能發現記憶體不安全問題，有效地阻止未定義行為的發生。

記憶體安全的 Bug 和併發安全的 Bug 產生的內在原因是相同的，都是因為記憶體的不正當訪問而造成的。同樣，利用裝載了所有權的強大類型系統，Rust 還解決了併發安全的問題。Rust 編譯器會通過靜態檢查分析，在編譯期就檢查出多執行緒併發程式碼中所有的資料競爭問題。

Unsafe Rust ：劃分安全邊界

為了和現有的生態系統良好地整合，Rust 支援非常方便且零成本的 FFI 機制，相容 C-ABI，並且從語言架構層面上將 Rust 語言分成 Safe Rust 和 Unsafe Rust 兩部分。

其中 Unsafe Rust 專門和外部系統打交道，比如作業系統核心。之所以這樣劃分，是因為 Rust 編譯器的檢查和跟蹤是有能力範圍的，它不可能檢查到外部其他語言介面的安全狀態，所以只能靠開發者自己來保證安全。

Rust 的最終目標並不是完全消除那些危險點，因為在某種程度上，我們需要能夠訪問記憶體和其他資源。實際上，Rust 的目標是將所有的unsafe元素抽象出來。在考慮安全性時，你需要考慮「攻擊面」，或者我們可以與程式的哪些部分進行互動。像解析器這樣的東西是一個很大的攻擊面，因為：

• 它們通常可以被攻擊者訪問；

• 攻擊者提供的資料可以直接影響解析通常需要的複雜邏輯。

  你可以進一步分解，將傳統的攻擊面分解成「攻擊面」（可以直接影響程式程式碼的部分）和「安全層」，這部分程式碼是攻擊面依賴的程式碼，但是無法訪問，而且可能存在潛在的 Bug。在 C 語言中，它們是一樣的：C 語言中的陣列根本不是抽象的，所以如果你讀取了可變數量的項，就需要確保所有的不變數都保持不變，因為這是在不安全層中操作，那裡可能會發生錯誤。

所以，Rust 提供了 unsafe  關鍵字和unsafe塊，顯式地將安全程式碼和訪問外部介面的不安全程式碼進行了區分，也為開發者偵錯錯誤提供了方便。Safe Rust 表示開發者將信任編譯器能夠在編譯時保證安全，而 Unsafe Rust 表示讓編譯器信任開發者有能力保證安全。

有人的地方就有 Bug。Rust 語言通過精緻的設計，將機器可以檢查控制的部分都交給編譯器來執行，而將機器無法控制的部分交給開發者自己來執行。

Safe Rust 保證的是編譯器在編譯時最大化地保障記憶體安全，阻止未定義行為的發生。

Unsafe Rust 用來提醒開發者，此時開發的程式碼有可能引起未定義行為，請謹慎！人和編譯器共享同一個「安全模型」，相互信任，彼此和諧，以此來最大化地消除人產生 Bug 的可能。

Unsafe Rust，是Rust的安全邊界。世界的本質就是Unsafe的。你無法避免它。還有人說，因為Unsafe Rust的存在，所以也不見得能比C/C++安全到哪裡去？Unsafe Rust確實和C/C++一樣，要靠人來保證它的安全。但它對人的要求更高。

它也給了開發者一個Unsafe的邊界，這其實也是一種安全邊界。它把你程式碼裡的雷區，顯式地標記了出來。團隊程式碼裡review的話，可以更快地發現問題。這本身就是一種安全。而反觀C++，你寫出的每一行程式碼都是Unsafe的，因為它沒有像Rust這樣明顯的界限（Unsafe 塊）。

以下是我總結的五條使用Unsafe的簡單規範，方便大家做權衡：

1. 能用Safe Rust就用Safe Rust；
2. 為了效能可以使用Unsafe Rust；
3. 在使用Unsafe Rust的時候確保不要產生UB，並且儘量判斷其安全邊界，抽象為 Safe 方法；
4. 如果無法抽象為Safe，需要標註為Unsafe，並配以產生UB的條件文件；
5. 對於Unsafe的程式碼，大家可以重點review。

所以，Unsafe 使用不當也會引發記憶體安全或邏輯 Bug 。所以，學習 如何對 Unsafe Rust 進行安全抽象至關重要。

不過，Rust 社群生態中有一個 Rust 安全工作組，該組提供 cargo-audit等一系列工具[11]，並且維護`RustSecurity` 安全資料庫庫[12]中記錄的Rust生態社群中發現的安全問題。可以方便地檢查 Rust 項目中依賴庫的安全問題。

生產力

程式語言生產力，大概可以通過以下三個方面來評估：

1. 學習曲線。
2. 語言工程能力。
3. 領域生態。

學習曲線

學習曲線的高低，依個人水平不同而不同。以下羅列了不同基礎學習 Rust 應該注意的地方。

1. 完全零基礎的開發者：掌握計算機基礎體系知識結構，理解Rust語言和硬體/OS層的抽象，理解Rust語言核心概念、以及它的抽象模式，選擇Rust語言的某個適用領域進行實操訓練，通過實踐來提升Rust語言的熟練度和理解深度，同時掌握領域知識。

2. 有C語言基礎：由於C語言開發者對高階語言的抽象不是很理解，所以著重瞭解掌握Rust所有權機制，包括所有權的語義，生命週期和借用檢查。瞭解Rust語言的抽象模式，主要是類型和trait；以及Rust本身的的OOP和函數式語言特性。

3. 有C++基礎：C++開發者對於Rust語言的所有權有很好的理解能力，主要精力放在Rust的抽象模式和函數式語言特性上。

4. 有Java/Python/Ruby基礎：著重理解攻克Rust所有權機制、抽象模式、函數語言程式設計語言特性。

5. 有Go基礎：Go語言開發者比較容易理解Rust的類型和trait抽象模式，但Go也是GC語言，所以所有權機制和函數式語言特性是他們的學習重點。

6. 有Haskell基礎：Haskell系的開發者對Rust語言函數式特效能很好的理解，主要攻克所有權機制和OOP語言特性。

所以，對於有一定基礎的開發者來說，學習Rust語言要掌握的幾個關鍵概念有：

1、Rust所有權機制，包括所有權的語義，生命週期和借用檢查

所有權機制是Rust語言最核心的特性，它保證了在沒有垃圾回收機制下的記憶體安全，所以對於習慣了GC的開發者，理解Rust的所有權是最關鍵的一環，切記這三點：

• Rust中的每一個值都有一個被稱為其所有者 (owner)的變數。
• 值有且只有一個所有者。
• 當所有者（變數）離開作用域，這個值將被丟棄。這其中又涉及到生命週期和借用檢查等概念，是相對比較難啃的一塊硬骨頭。

2、Rust語言的抽象模式，主要是類型和trait。trait借鑑了Haskell中的Typeclass，它是對類型行為的抽象，可以通俗地類比為其他程式語言裡的介面，它告訴編譯器一個類型必須提供哪些功能語言特性。使用時要遵循一致性，不能定義相互衝突的實現。

3、OOP語言特性。熟悉面向物件程式設計（OOP）的常見的四個特性：物件、封裝、繼承和多型，可以更好地理解Rust的一些特性，比如impl、pub、trait等等。

4、函數式語言特性。Rust語言的設計深受函數語言程式設計的影響，看到函數式特性，數學不好的人可能會望而卻步，因為函數語言程式設計語言的最大特點是把運算過程儘量寫成一系列巢狀的函數呼叫,在Rust中，掌握閉包和迭代器是編寫函數式語言風格的高效能Rust程式碼的重要一環。

語言工程能力

Rust 已經為開發工業級產品做足了準備。

為了保證安全性，Rust 引入了強大的類型系統和所有權系統，不僅保證記憶體安全，還保證了併發安全，同時還不會犧牲效能。

為了保證支援硬實時系統，Rust 從 C++那裡借鑑了確定性析構、RAII 和智慧指針，用於自動化地、確定性地管理記憶體，從而避免了 GC 的引入，因而就不會有「世界暫停」的問題了。這幾項雖然借鑑自 C++，但是使用起來比 C++更加簡潔。

為了保證程式的健壯性，Rust 重新審視了錯誤處理機制。日常開發中一般有三類非正常情況：失敗、錯誤和異常。但是像 C 語言這種面向過程的語言，開發者只能通過返回值、goto 等語句進行錯誤處理，並且沒有統一的錯誤處理機制。而 C++和 Java 這種高階語言雖然引入了異常處理機制，但沒有專門提供能夠有效區分正常邏輯和錯誤邏輯的語法，而只是統一全局進行處理，導致開發者只能將所有的非正常情況都當作異常去處理，這樣不利於健壯系統的開發。並且異常處理還會帶來比較大的效能開銷。

Rust 語言針對這三類非正常情況分別提供了專門的處理方式，讓開發者可以分情況去選擇。

• 對於失敗的情況，可以使用斷言工具。
• 對於錯誤，Rust 提供了基於返回值的分層錯誤處理方式，比如 Option 可以用來處理可能存在空值的情況，而 Result 就專門用來處理可以被合理解決並需要傳播的錯誤。
• 對於異常，Rust 將其看作無法被合理解決的問題，提供了執行緒恐慌機制，在發生異常的時候，執行緒可以安全地退出。

通過這樣精緻的設計，開發者就可以從更細的粒度上對非正常情況進行合理處理，最終編寫出更加健壯的系統。

為了提供靈活的架構能力，Rust 使用 特質（trait） 來作為零成本抽象的基礎。特質 面向組合而非繼承，讓開發者可以靈活地架構 緊耦合 和 鬆耦合的系統。Rust 也提供了 泛型 來表達類型抽象，結合 trait 特性，讓 Rust 擁有靜態多型 和 程式碼複用 的能力。泛型和trait 讓你可以靈活使用各種設計模式來對系統架構進行重塑。

為了提供強大的語言擴展能力和開發效率，Rust 引入了基於宏的超程式設計機制。Rust提供了兩種宏，分別是聲明宏和過程宏。聲明宏的形式和C的宏替換類似，區別在於Rust會對宏展開後的程式碼進行檢查，在安全方面更有優勢。過程宏則讓 Rust 在程式碼複用、程式碼生成擁有強大的能力。

為了和現有的生態系統良好地整合，Rust 支援非常方便且零成本的 FFI 機制，相容 C-ABI，並且從語言架構層面上將 Rust 語言分成 Safe Rust 和 Unsafe Rust 兩部分。其中 Unsafe Rust 專門和外部系統打交道，比如作業系統核心。之所以這樣劃分，是因為 Rust 編譯器的檢查和跟蹤是有能力範圍的，它不可能檢查到外部其他語言介面的安全狀態，所以只能靠開發者自己來保證安全。Unsafe Rust 提供了 unsafe 關鍵字和 unsafe 塊，顯式地將安全程式碼和訪問外部介面的不安全程式碼進行了區分，也為開發者偵錯錯誤提供了方便。Safe Rust 表示開發者將信任編譯器能夠在編譯時保證安全，而 Unsafe Rust 表示讓編譯器信任開發者有能力保證安全。

有人的地方就有 Bug。Rust 語言通過精緻的設計，將機器可以檢查控制的部分都交給編譯器來執行，而將機器無法控制的部分交給開發者自己來執行。Safe Rust 保證的是編譯器在編譯時最大化地保障記憶體安全，阻止未定義行為的發生。Unsafe Rust 用來提醒開發者，此時開發的程式碼有可能引起未定義行為，請謹慎！人和編譯器共享同一個「安全模型」，相互信任，彼此和諧，以此來最大化地消除人產生 Bug 的可能。

為了讓開發者更方便地相互協作，Rust 提供了非常好用的包管理器Cargo[13]。Rust 程式碼是以包（crate）為編譯和分發單位的，Cargo 提供了很多命令，方便開發者創建、構建、分發、管理自己的包。Cargo 也提供插件機制，方便開發者編寫自定義的插件，來滿足更多的需求。比如官方提供的 rustfmt 和 clippy 工具，分別可以用於自動格式化程式碼和發現程式碼中的「壞味道」。再比如，rustfix 工具甚至可以幫助開發者根據編譯器的建議自動修復出錯的程式碼。Cargo 還天生擁抱開源社群和 Git，支援將寫好的包一鍵釋出到 crates.io 網站，供其他人使用。

為了方便開發者學習 Rust，Rust 官方團隊做出瞭如下努力：

• 獨立出專門的社群工作組，編寫官方 Rust Book，以及其他各種不同深度的文件，比如編譯器文件、nomicon book 等。甚至組織免費的社群教學活動 Rust Bridge，大力鼓勵社群部落格寫作，等等。
• Rust 語言的文件支援 Markdown 格式，因此 Rust 標準庫文件表現力豐富。生態系統內很多第三方包的文件的表現力也同樣得以提升。
• 提供了非常好用的線上 Playground 工具，供開發者學習、使用和分享程式碼。
• Rust 語言很早就實現了自舉，方便學習者通過閱讀源碼瞭解其內部機制，甚至參與貢獻。
• Rust 核心團隊一直在不斷改進 Rust，致力於提升 Rust 的友好度，極力降低初學者的心智負擔，減緩學習曲線。比如引入 NLL 特性來改進借用檢查系統，使得開發者可以編寫更加符合直覺的程式碼。
• 雖然從 Haskell 那裡借鑑了很多類型系統相關的內容，但是 Rust 團隊在設計和宣傳語言特性的時候，會特意地去學術化，讓 Rust 的概念更加親民。
• 在類型系統基礎上提供了混合程式設計正規化的支援，提供了強大而簡潔的抽象表達能力，極大地提升了開發者的開發效率。
• 提供更加嚴格且智慧的編譯器。基於類型系統，編譯器可以嚴格地檢查程式碼中隱藏的問題。Rust 官方團隊還在不斷優化編譯器的診斷資訊，使得開發者可以更加輕鬆地定位錯誤，並快速理解錯誤發生的原因。

為了方便 Rust 開發者提升開發效率，Rust 社群還提供了強大的 IDE 支援。VSCode/Vim/Emacs + Rust Analyzer 成為了 Rust 開發的標配。當然 JetBrains家族的 IDEA/ Clion  也對 Rust 支援十分強力。

Rust 與 開源

Rust 語言自身作為一個開源項目，也是現代開源軟體中的一顆璀璨的明珠。

在 Rust 之前誕生的所有語言，都僅僅用於商用開發，但是 Rust 語言改變了這一狀況。對於 Rust 語言來說，Rust 開源社群也是語言的一部分。同時，Rust 語言也是屬於社群的。

Rust 團隊由 Mozilla 和非 Mozilla 成員組成，至今 Rust 項目貢獻者已經超過了 1900 人。Rust 團隊分為核心組和其他領域工作組，針對 Rust 2018 的目標，Rust 團隊被分為了嵌入式工作組、CLI 工作組、網路工作組以及 WebAssembly 工作組，另外還有生態系統工作組和社群工作組等。

這些領域中的設計都會先經過一個 RFC 流程，對於一些不需要經過 RFC 流程的更改，只需要給 Rust 項目庫提交 Pull Request 即可。所有過程都是對社群透明的，並且貢獻者都可參與評審，當然，最終決策權歸核心組及相關領域工作組所有。後面為了精簡 FCP流程，也引入了 MCP。

Rust 團隊維護三個發行分支：穩定版（Stable）、測試版（Beta）和開發版（Nightly）。其中穩定版和測試版每 6 周釋出一次。標記為不穩定（Unstable）和特性開關（Feature Gate）的語言特性或標準庫特性只能在開發版中使用。

在 Rust 基金會成立以後，Rust 團隊也在不斷探索新的開源治理方案。

Rust 語言的不足

Rust 雖然有很多優勢，但肯定也存在一些缺點。

1. Rust 編譯速度很慢。雖然 Rust 官方也一直在改進 Rust 編譯速度，包括增量編譯支援，引入新的編譯後端（ cranelift ），並行編譯等措施，但還是慢。而且 增量編譯目前也有 Bug。
2. 學習曲線陡峭。
3. IDE 支援不夠完善。比如，對宏程式碼的支援不是很好。
4. 缺乏針對 Rust 語言特有記憶體不安全問題的各種檢測工具。

Rust 生態基礎庫和工具鏈

Rust 生態日趨豐富，很多基礎庫和框架都會以 包（crate） 的方式釋出到 crates.io[14] ，截止目前，crates.io 上面已經有 62981 個 crate，總下載量已經達到 7,654,973,261次。

按包的使用場景分類，Crates.io 最流行的幾個場景依次如下：

• 命令列工具 （3133  crates）
• no-std 庫 （2778   crates）
• 開發工具（測試/ debug/linting/效能檢測等， 2652 crates）
• Web 程式設計 （1776 crates）
• API 繫結 （方便 Rust 使用的特定 api 包裝，比如 http api、ffi 相關api等，1738 crates）
• 網路程式設計 （1615 crates）
• 資料結構 （1572 crates）
• 嵌入式開發 （1508 crates）
• 加密技術（1498 crates）
• 非同步開發（1487 crates）
• 演算法 （1200 crates）
• 科學計算（包括物理、生物、化學、地理、機器學習等，1100 crates）

除此之外，還有  WebAssembly 、編碼、文字處理、併發、GUI、遊戲引擎、視覺化、模版引擎、解析器、作業系統繫結 等其他分類，也有不少庫。

常用知名基礎庫和工具鏈

其中已經湧現出不少優秀的基礎庫，都可以在 crates.io 首頁裡看到。這裡羅列出一些：

• 序列化/反序列化：Serde[15]

• 命令列開發：clap [16]/  structopt[17]

• 非同步/Web/網路開發：tokio [18] / tracing [19] /async-trait [20] / tower [21]/ async-std [22] tonic [23]/ actix-web [24]/smol [25]/ surf [26]/ async-graphql [27]/ warp /[28] tungstenite [29]/  encoding_rs [30]/ loom [31]/ Rocket[32]

• FFi 開發：libc [33]/ winapi [34]/ bindgen [35]/ pyo3 [36]/ num_enum [37]/ jni [38]/ rustler_sys[39]/ cxx [40]/ cbindgen [41]/ autocxx-bindgen [42]

• API 開發: jsonwebtoken [43]/ validator [44]/ tarpc [45]/ nats [46]/ tonic[47]/ protobuf [48]/ hyper [49]/ httparse [50]/ reqwest [51] / url [52]

• 解析器：nom [53]/ pest [54]/ csv [55]/ combine [56]/ wasmparser [57]/ ron [58]/ lalrpop [59]

• 密碼學：openssl [60]/ ring [61]/ hmac [62]/ rustls[63]  / orion[64] / themis[65] / RustCrypto[66]

• WebAssembly:   wasm-bindgen[67]/ wasmer [68]/ wasmtime [69]/ yew [70]

• 資料庫開發：diesel [71]/  sqlx [72]/ rocksdb [73]/ mysql [74]/ elasticsearch [75]/ rbatis [76]

• 併發：crossbeam [77]/ parking_lot [78]/ crossbeam-channel [79]/ rayon [80]/ concurrent-queue[81]/ threadpool [82] / flume [83]

• 嵌入式開發：embedded-hal [84]/ cortex-m [85]/ bitvec [86]/ cortex-m-rtic [87]/ embedded-dma [88]/ cross [89]/ Knurling Tools[90]

• 測試：static_assertions [91]/ difference [92]/ quickcheck [93]/ arbitrary [94]/ mockall [95]/ criterion [96]/ proptest[97] / tarpaulin[98]/ fake-rs[99]

• 多媒體開發：rust-av[100]/ image[101]/ svg [102]/ rusty_ffmpeg[103]/ Symphonia[104]/

• 遊戲引擎和基礎元件：glam [105]/ sdl2 [106]/ bevy [107]/ amethyst[108]/ laminar[109]/ ggez [110]/ tetra[111]/ hecs[112]/ simdeez[113]/ rg3d [114] / [rapier](https://github.com/dimforge/ra pier "rapier") / Rustcraft[115] Nestadia[116]/ naga[117]/ Bevy Retro[118]/ Texture Generator[119] / building_blocks[120] / rpg-cli [121]/ macroquad[122]

• TUI/GUI 開發：winit [123]/ gtk [124]/ egui [125]/ imgui [126]/ yew [127]/ cursive [128]/ iced [129]/ fontdue [130]/ tauri [131]/ druid [132]

Rust 行業應用盤點

Rust 是一門通用的高階系統級程式語言，其應用領域基本可以同時覆蓋 C/Cpp/Java/Go/Python 的應用領域。

具體而言，Rust 的應用領域目前覆蓋到以下領域：

下面來盤點不同領域內國內外的 Rust 項目。通過提供程式碼量、團隊規模、項目週期相關資料，希望可以讓大家對 Rust 領域應用和開發效率能有一個比較直觀的認識。

資料服務

資料服務領域，包括了資料庫，資料倉儲，資料流，大資料等。

TiKV（國內/開源/分散式資料庫）

關鍵字：資料庫/ 分散式系統/ CNCF

介紹

TiKV [133]是一個開源的分散式事務 Key-Value 資料庫，專注為下一代資料庫提供可靠、高質量、實用的儲存架構。最初由 PingCAP 團隊在 目前，TiKV 已經在知乎、一點資訊、Shopee、美團、京東雲、轉轉等多行業頭部企業得到上線應用。

TiKV 通過 Raft 一致性演算法來實現資料多副本之間的一致性，本地採用了 RocksDB 儲存引擎儲存資料，同時 TiKV 支援資料自動切分和遷移。TiKV 的跨行事務最初參考 Google Percolator 事務模型，並進行了一些優化，提供快照隔離與帶鎖快照隔離，支援分散式事務。

2018 年 8 月被 CNCF 宣佈接納為沙箱雲原生項目，在 2019 年 5 月從沙箱晉級至孵化項目。

程式碼與團隊規模

TiKV 項目 包含 Rust 程式碼行數大約 30 萬行（包含測試程式碼）。

TiKV 是全球性開源項目，可以從貢獻者名單[134]來檢視團隊規模。TiKV 組織中也包含了一些 Go/Cpp 項目，這個並不算在內，只統計參與 Rust 項目的人力規模。

• 主力開發：20人左右。
• 社群貢獻：300 多人。

項目週期

TiKV 是作為 TiDB 的底層儲存跟隨 TiDB 演進。TiDB 為 Go 開發，TiKV 為 Rust 開發。

2016 年 1 月作為 TiDB 的底層儲存引擎設計並開發 。

2016 年 4 月開源 釋出第一版。

2017 年 10 月 16 日，TiDB 釋出 GA 版（TiDB 1.0）， TiKV 釋出 1.0 。

2018 年 4 月 27 日，TiDB 釋出 2.0 GA 版， TiKV 釋出 2.0 。

2019 年 6 月 28 日，TiDB 釋出 3.0 GA 版本， TiKV 釋出 3.0 。

2020 年 5 月 28 日，TiDB 釋出 4.0 GA 版本， TiKV 釋出 4.0。

2021 年 4 月 07 日，TiDB 釋出 5.0 GA 版本， TiKV 釋出 5.0。

小評

有些朋友可能比較關注 Rust 開發效率如何，並且想對其量化，尤其是想對比 C/ Cpp / Go 等其他語言的開發效率。

私以為量化開發效率是非常困難的，尤其是和其他語言比較的量化。我們不妨換個角度來看這件事，比如，從敏捷項目迭代管理來看這件事。如果一門語言，可以滿足日常的敏捷開發迭代需求，可以幫助完成產品的進化，那足以說明這門語言的開發效率了。

據瞭解，PingCAP 中 Go 開發人員是 Rust 開發人員的四五倍之多，當然工作量也差不多是這樣的比例。從上面的資料，我們可以看得出來， Rust 項目（TiKV）依然可以穩步跟得上 Go 項目（TiDB）的迭代節奏，說明 Rust 的開發效率還是足以勝任現代化開發需求。

TensorBase （國內/開源/實時資料倉庫）

關鍵字：實時資料倉庫/ 創業/ 天使輪

介紹

TensorBase[135] 是金明劍博士於 2020 年 8月啟動的創業項目，從一個現代的全新視角出發，用開源的文化和方式，重新構建一個Rust下的實時資料倉庫，服務於這個海量資料時代的資料儲存和分析。TensorBase 項目目前已獲得世界知名創業投資加速機構的天使輪投資。

程式碼與團隊規模

因為 TensorBase 是構建於 Apache Arrow[136] 和 Arrow DataFusion[137] 之上，所以程式碼統計排除掉這兩個項目的依賴。

TensorBase 核心程式碼行數 54000 多行。

團隊規模：

• 主力開發：1人。
• 社群貢獻：13 人。

因為是新項目，開源社群還在建設中。

項目週期

TensorBase 以時間為節奏發版，而非語義版。迭代週期預計 一年一個大版本，一月一個小版本。

從 2021年 4 月 20 正式發版，到最近 6月 16，保持這個節奏。

Timely Dataflow (國外/開源/實時資料流)

關鍵字：Dataflow/ 分散式系統/創業

介紹

Timely Dataflow[138] 是 基於微軟 這篇 Timely Dataflow 論文：《Naiad: A Timely Dataflow System》[139]的 現代化 Rust 實現。是 clockworks.io[140] 公司的開源產品。

在分散式系統中對流式資料進行復雜的處理，比如多次迭代或者遞增計算是非常困難的。Storm, Streaming Spark, MillWheel 都不能很好的適應各種應用複雜的需求。Naiad 通過引入 timestamp 的概念，給出了一個非常 low-level 的模型，可以用來描述任意複雜的流式計算。

dataflow系統包羅萬象，MapReduce，Spark都可以算是其中代表。Timely dataflow 給出了一個完全基於時間的抽象，統一了流式計算和迭代計算。當你需要對流式資料並行處理且需要迭代控制的時候，可以使用 Timely Dataflow 。

程式碼與團隊規模

Rust 程式碼量 大約 13000 行。

團隊規模：

• 主力開發：4人。
• 社群貢獻：30多人。

項目週期

2017年9月7號，0.3.0 版本。

2018年6月28號，0.6.0 版本。

2018年9月16號，0.7.0 版本。

2018年12月3號，0.8.0 版本。

2019年3月31號，0.9.0 版本。

2019年7月10號，0.10.0 版本。

2021年3月10號，0.12.0版本。

基本上 三個月 出 一個 小版本，除了 Timely Dataflow 之外該團隊同時還維護一個構建於 Timely Dataflow 之上的 Differential Dataflow[141] ，和 Timely Dataflow 同步迭代。

Noria （國外/學術研究/開源/資料庫）

關鍵字：資料庫/ 學術論文項目

介紹

Noria [142] 是一種新的流式資料流系統，旨在作為基於MIT  Jon Gjengset[143] 的博士學位論文[144]的重型Web應用程式的快速儲存後端，也參考了OSDI'18的論文[145]。它類似於資料庫，但支援預計算和快取關係查詢結果，以便加速查詢。Noria 自動將快取的結果保持為底層資料，儲存在永續性基礎表中。Noria使用部分狀態資料流來減少記憶體開銷，並支援動態，運行時資料流和查詢更改。

程式碼與團隊規模

Rust 程式碼行數大約 59000 多行。

團隊規模：

• 主力貢獻者：2人
• 社群貢獻者：21人

項目週期

因為是個人學術研究項目，所以釋出週期沒有那麼明顯。

項目週期 2016年7月30 ~ 2020年 4月30，一共5000多commit。

Vector （國外/開源/資料管道）

關鍵字：資料管道/分散式系統/創業

Vector[146] 是 Timer 公司構建的一款高效能的、端到端的（代理和聚合器）可觀察性資料管道。它是開源的，比該領域（Logstash、Fluentd之類）的所有替代方案快10倍。目前像 豆瓣、checkbox.ai、fundamentei、BlockFi、Fly.io 等公司使用了 Vector 。點選此處[147]檢視官方效能報告，點選此處[148]檢視目前生產環境中使用 Vector 的公司。

程式碼與團隊規模

程式碼量大約 18 萬行 Rust 程式碼。

團隊規模：

• 主力開發：9人
• 社群貢獻：140 人

項目週期

2019年3月22，初始版本釋出。

2019年6月10，0.2.0版本釋出

2019年7月2，0.3.0版本釋出

2019年9月25，0.4.0版本釋出

2019年10月11，0.5.0版本釋出

2019年12月13，0.6.0版本釋出

2020年1月12，0.7.0版本釋出

2020年2月26，0.8.0版本釋出

2020年4月21，0.9.0版本釋出

2020年7月23，0.10.0版本釋出

2021年3月12，0.11.0 ～ 0.12 版本釋出

2021年4月22，0.13.0版本釋出

2021年6月3，0.14.0版本釋出

Arrow-rs （國外/開源/大資料標準）

關鍵字：大資料/資料格式標準/Apach

arrow-rs[149] 是 Apache Arrow 的 Rust 實現。Apache Arrow 是 一種適合異構大資料系統的記憶體列存資料格式標準。它有一個非常大的願景：提供記憶體資料分析 (in-memory analytics) 的開發平臺，讓資料在異構大資料系統間移動、處理地更快。

Arrow 從 2.0 版本開始引入 Rust[150] ，從 4.0 開始 Rust 實現遷移到了獨立倉庫 arrow-rs 。

Arrow的Rust實現實際上由幾個不同的項目組成，包括以下幾個獨立 crate 和 庫 ：

• arrow[151]，arrow-rs 核心庫，包含在 arrow-rs 中。
• arrow-flight [152]，arrow-rs 元件之一，包含在 arrow-rs 中。
• parquet[153]，arrow-rs 元件之一，包含在 arrow-rs 中。在大資料生態內，Parquet 是最為流行的檔案儲存格式。
• DataFusion[154]，一個可擴展的記憶體查詢執行引擎，使用Arrow作為其格式。
• Ballista[155]，一個分散式計算平臺，由Apache Arrow和DataFusion驅動，包含在 DataFusion 中。

程式碼與團隊規模

arrow-rs 各相關元件加起來，Rust 程式碼量 大約 18 萬行。

團隊規模：

• 主力開發：大約 10 人

• 社群貢獻：550 多人

項目週期

項目 DataFusion 在 2016 年就開始構建了，後來進入了 Apache Arrow 項目。

以 arrow-rs 4.0 開始算：

2021 年 4 月 18 ，版本 4.0 釋出。

2021 年 5 月 18，版本 4.1 釋出。

2021 年 5 月 30， 版本 4.2 釋出。

2021 年 6 月11， 版本 4.3 釋出。

InfluxDB IOx （國外/ 開源/時序資料庫）

關鍵字：時序資料庫/分散式

InfluxDB IOx[156]，是 InfluxDB 的下一代時序引擎，使用 Rust + Aarow 來重寫。

現有設計主要有以下幾個致命性問題：

1. 無法解決時間線膨脹的問題
2. 在雲原生環境下，對記憶體管理要求比較嚴格，這意味 mmap 不在適用，而且 InfluxDB 需要支援無本地盤的運行模式
3. 由於索引與資料分開儲存，導致高效的資料匯入匯出功能難以實現

上述這三個問題都是現有設計的核心之處，因此要想支援現階段需求，重寫是個比較好的選擇。

程式碼與團隊規模

InfluxDB IOx 程式碼量大約是 16萬行 Rust 程式碼。

團隊規模：

• 主力開發：5人
• 社群貢獻：24 人

項目週期

該項目從 2019年 11月開始立項，但截至到今天此項目還非常早期，它還沒有準備好進行測試，也沒有任何構建或文件。

但是從 GitHub 活動狀態來看，開發狀態還非常積極。主要的開發工作都是在2021年開始的。

CeresDB （國內/商業/時序資料庫）

關鍵字：時序資料庫

介紹

CeresDB 是螞蟻集團研發的一款TP/AP 融合時序資料庫，滿足金融時序、監控、IOT 等場景下的海量時序資料的儲存、多維查詢下鑽和實時分析需求。有開源計劃，但目前暫未開源。

團隊規模

目前資料庫開發大約 8-10個人。

其他資訊還未可知。

tantivy (國外/開源/全文檢索)

關鍵字：全文檢索/ lucene

tantivy[157] 是一個由 Apache Lucene 啟發的全文搜尋引擎庫，用 Rust 實現。

tantivy 效能卓越，這裡有一個基於 Rust + Tantivy + AWS 構建的應用 ：提供十億網頁搜尋並生成常見單詞雲[158]。

程式碼及團隊規模

程式碼量大約為 50000 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人
• 社群貢獻：85人

項目週期

項目自 2016 年立項，迭代週期為平均一月一個小版本釋出，目前釋出到 0.15.2 版本。

Rucene （國內/開源/搜尋引擎）

關鍵字：知乎/ lucene

介紹

Rucene[159] 是知乎團隊開源的一款基於 Rust 實現的搜尋引擎。Rucene不是完整的應用程式，而是可以輕鬆用於將完整文字搜尋功能新增到應用程式的程式碼庫和API。它是對 Apache Lucene 6.2.1 項目的 Rust 移植。

程式碼及團隊規模

程式碼量大約為 10 萬 行 Rust 程式碼。

團隊規模：

• 主力開發：4人
• 社群貢獻：0 人

項目週期

可能因為是公司內部項目開源化，目前沒有迭代出具體語義版本。在知乎內是用於生產環境的。

雲原生

雲原生領域包括：機密計算、Serverless、分散式計算平臺、容器、WebAssembly、運維工具等

StratoVirt （國內/開源/容器）

關鍵字：容器/ 虛擬化/ Serverless

StratoVirt[160] 是 華為 OpenEuler 團隊研發的 基於Rust的下一代虛擬化平臺。

Strato，取自stratosphere，意指地球大氣層中的平流層，大氣層可以保護地球不受外界環境侵害，而平流層則是大氣層中最穩定的一層；類似的，虛擬化技術是作業系統平臺之上的隔離層，既能保護作業系統平臺不受上層惡意應用的破壞，又能為正常應用提供穩定可靠的運行環境；以Strato入名，寓意為保護openEuler平臺上業務平穩運行的輕薄保護層。同時，Strato也承載了項目的願景與未來：輕量、靈活、 安全和完整的保護能力。

StratoVirt是計算產業中面向雲資料中心的企業級虛擬化平臺，實現了一套架構統一支援虛擬機器、容器、Serverless三種場景，在輕量低噪、軟硬協同、安全等方面具備關鍵技術競爭優勢。StratoVirt在架構設計和介面上預留了元件化拼裝的能力和介面，StratoVirt可以按需靈活組裝高階特性直至演化到支援標準虛擬化，在特性需求、應用場景和輕快靈巧之間找到最佳的平衡點。

程式碼與團隊規模

程式碼量大約是 27000 行 Rust 程式碼。

團隊規模：

• 主力開發：4 人。
• 社群貢獻：15人。

項目週期

2020-09-23，釋出 0.1.0 版本。

2021-03-25，釋出 0.2.0 版本。

2021-05-28 ，釋出 0.3.0 版本。

Firecracker （國外/產品）

關鍵字：容器/ Serverless/ FaaS

Firecracker[161] 由 AWS 釋出並將firecracker開源， 它的定位是面向Serverless計算業務場景。Firecracker本質上是基於KVM的輕量級的microVM， 可以同時支援多租戶容器和FaaS場景。Security和Fast是firecracker的首要設計目標。它的設計理念可以概括為：

• 基於KVM
• 精簡的裝置集（極簡主義）
• 基於Rust語言（Builtin Safety）
• 定製的guest kernel（快速啟動）
• 優化記憶體開銷（使用musl c）

Firecracker使用了極為精簡的裝置模型（僅有幾個關鍵的模擬裝置），目的是減少攻擊面已提升安全性。同時這irecracker使用了一個精簡的核心（基於Apline Linux），這使得Firecracker可以做在125ms內拉起一個虛擬機器。Firecracker使用musl libc而不是gnu libc，能夠將虛擬機器的最低記憶體開銷小到5MB。

程式碼及團隊規模

程式碼量大約為 75000 多行。

團隊規模：

• 主力開發：7人
• 社群貢獻：140 人

項目週期

從 2018年 3月5號 釋出 0.1.0 開始，基本上是每個月發一個小版本。

截止到上個月，剛釋出了 0.24.0 版本。

Krustlet （國外/產品）

關鍵字：Kubernetes/ WebAssembly/ 容器

介紹

微軟 Deis Labs[162]釋出了Krustlet[163]，它是使用 Rust 實現的一種 Kubernetes kubelet。它監聽 Kubernetes API，以獲取新的 Pod 請求（在叢集中運行基於 WASI 的應用程式），只要請求事件與節點選擇器是匹配的。因此，要在 Krustlet 節點上運行應用程式，使用者可以使用 taints、tolerations 和節點選擇器。此外，使用者必須為應用程式生成 WebAssembly 二進位制檔案。如果應用程式是用 C 語言開發的，就用clang[164]，如果應用程式是用 Rust 開發的，就用cargo[165]。然後，使用者必須使用wasm-to-oci[166]打包，並將容器映象推送到容器註冊中心。要部署應用程式，使用者需要定義一個 Kubernetes 清單，其中包含 tolerations。

目前該項目還未到 1.0，有很多實驗性特性，但是它的存在證明了 WebAssembly 在容器方面的應用方向。但現在 微軟加入了 位元組碼聯盟 ，該項目也會連同位元組碼聯盟的其他成員，一起發展 WebAssembly，特別是即將到來的WASI規範工作和模組連結。

程式碼及團隊規模

程式碼量大約為 21000 多行。

團隊規模：

• 主力開發：7人
• 社群貢獻：32人

項目週期

自從 2020 年 4月7日，0.1.0 釋出以來，大約每一兩個月釋出一次新版本，目前釋出到 0.7.0 版本。

團隊有計劃在未來幾個月內達到 1.0 版本。

linkerd2-proxy （國外/產品）

關鍵字：服務網格/ k8s

介紹

Linkerd 算是 服務網格的鼻祖，但是由於 Linkerd-proxy 運行需要 Java 虛擬機器的支援，在啟動時間、預熱、記憶體消耗等方面，相比起晚它半年釋出的挑戰者 Envoy 均處於全面劣勢。後來才重寫了 Linkerd2 。

Linkerd2 （曾命名為 Conduit[167]） 是 Buoyant 公司推出的下一代輕量級服務網格框架。與 linkerd 不同的是，它專用於 Kubernetes 叢集中，並且比 linkerd 更輕量級（基於 Rust 和 Go，沒有了 JVM 等大記憶體的開銷），可以以 sidecar 的方式把代理服務跟實際服務的 Pod 運行在一起（這點跟 Istio 類似）。

linkerd2-proxy [168] 是 Linkerd2 中的底層代理。代理可以說是服務網格中最關鍵的元件。它可以隨應用程式的部署而擴展，因此低附加延遲和低資源消耗至關重要。它也是處理應用程式所有敏感資料的地方，因此安全性至關重要。如果代理速度慢、臃腫或不安全，那麼服務網格也是如此。使用 Rust 重寫後，Linkerd2-proxy[169]的效能與資源消耗方面都已不輸 Envoy。

Rust是Linkerd2-proxy的唯一選擇。它提供了閃電般的效能、可預見的低延遲和我們知道服務網格代理需要的安全屬性。它還提供了現代語言特性，如模式匹配和富有表現力的靜態類型系統，以及工具，如內建的測試框架和包管理器，使在其中程式設計變得非常愉快。

Linkerd2-proxy 構建在 Rust 非同步生態之上，使用了Tokio[170], Hyper[171], and Tower[172] 等框架和庫。

程式碼及團隊規模

程式碼量大約為 43000 多行。

團隊規模：

• 主力開發：3 人。
• 社群貢獻：37 人。

項目週期

目前該項目已經是 V2.148.0 版本。釋出週期大約是每週一個小版本。

Lucet （國外/產品）

關鍵字：Faas/ Serverless/ WebAssembly / Compiler

Lucet[173] 是一個本機 Webassembly 編譯器和運行時。它旨在安全地在您的應用程式內執行不受信任的 WebasseMbly 程式。由 Fastly 公司開發，屬於 位元組碼聯盟 的子項目。Fastly 於 2020 年從 Mozilla 招募了 WebAssembly Server side 團隊，目前 lucet 團隊已經和 wasmtime[174] 團隊合併。

Fastly 龐大的 CDN 業務催生了它們進軍邊緣計算的想法，並逐漸成為其中最具競爭力和投入度最高的頭部公司。

關於邊緣計算，另外一家頭部公司是Cloudflare(NET.US)。從技術角度看，Fastly和Cloudflare在其無伺服器邊緣計算解決方案中採用了兩種不同的方法。

Cloudflare選擇在Chromium V8引擎上構建其解決方案。這使得他們可以利用Google(GOOG.US) Chrome團隊已經完成的工作，在2018年便將邊緣計算產品快速推向市場。

這是對當時由雲供應商(如Amazon(AMZN.US) Lambda)提供的無伺服器解決方案的重大改進。Cloudflare的工作者將冷啟動時間減少了100倍，進入到毫秒階段。並將記憶體使用量減少了10倍，從而可以更有效地利用硬體資源。

但Fastly決定不依賴現有技術來進行無伺服器計算，例如可重複使用的容器或V8引擎，而是決定全心投入WebAssembly，並構建了自己的Lucet編譯器和運行時，對效能、安全性和緊湊性進行了優化。

自2017年以來，Fastly一直在幕後進行這項工作，它為Compute@Edge產品線提供了堅實的基礎，該平臺現在為多個客戶運行生產程式碼。

Lucet將WebAssembly編譯為快速、有效的二進位制檔案以便執行，還可以通過記憶體分配來增強安全性，並且不會從先前的請求中產生任何殘留。Lucet還包括一個經過嚴格優化的簡化運行時環境，Fastly團隊在該環境上花費了大部分開發時間。結果獲得了比V8引擎更好的效能。

Fastly冷啟動時間完全進入微秒級別--官方宣稱為35微秒。這至少比V8引擎快100倍，後者需要3-5毫秒才能啟動(3,000到5,000微秒)。

同樣，由於Lucet僅包含運行已編譯的彙編程式碼所需的程式碼模組，因此它只需要幾千位元組的記憶體。這大約是V8引擎使用的3MB的千分之一。

程式碼與團隊規模

lucet 程式碼量為 29000 多行， wasmtime 總程式碼量為 27萬多行。

團隊規模：

• 主力開發 ：16 人。
• 社群貢獻：200 多人 （wasmtime 貢獻者居多）

項目週期

lucet 目前進入維護期，wasmtime在高速重構。

評價迭代週期為 每個月發一個小版本。

wasmcloud （國外/開源/產品）

關鍵字：WebAssembly/ 分散式計算

介紹

WasmCloud[175] 運行時可以用於雲、瀏覽器和嵌入式等場景。wasmcloud 是一個基於 WebAssembly 的分散式計算平臺。比較有創新的地方在於，它制定了一個 waPC 標準，用於 Guest 和 Host 的安全過程呼叫，來解決當前 WASI 等特性不完善的問題。

程式碼及團隊規模

程式碼量大約為 11000 多行 Rust 程式碼。

團隊規模：

• 主力開發：2 人。
• 社群貢獻：11 人。

項目週期

該項目從 2021 年 2月17 啟動，迭代週期大約是每兩週一個小版本。

Habitat （國外/開源/運維工具）

關鍵字：Chef/ DevOps/ 運維工具

介紹

Habitat[176] 讓應用團隊能夠在任何環境中構建、部署、管理任何應用 ，不管是傳統的資料中心，還是容器化的微服務。

• 「Lift & Shift」 遺留應用到現代平臺 。把已有的、對商業至關重要的應用遷移到現代平臺上對許多機構來說 是一個痛點。
• 通過雲原生（雲、容器）的策略來交付 應用 。許多機構在移居和部署雲原生平臺的 過程中備受阻礙。

特點：

1. Habitat 把管理介面和應用構建在一起，使得自 動化更加簡便。

2. Habitat Operator：讓你的所有應用僅需一個 Kubernetes Operator，不需 要每個應用都有特製的 Operator。

3. 不管你的應用在不在 Kubernetes 上，Habitat 的 Open Service Broker 都能通過 Kubernetes 的原生介面讓它們共存。

程式碼及團隊規模

程式碼量大約為 74000 行 Rust 程式碼。

團隊規模：

• 主力開發：5 人。
• 社群貢獻：140人

項目週期

迭代週期為每週一個小版本，目前版本為 1.6.342。

作業系統

作業系統領域包括使用 Rust 實現的各種作業系統。

Rust for Linux （國外/ Rust 進入 Linux 支援項目 ）

關鍵字：Linux

介紹

Rust for Linux[177] 項目旨在推動 Rust 成為 Linux 核心第二程式語言。

Linux核心是現代網際網路的核心，從伺服器到客戶端裝置。它處於處理網路資料和其他形式的輸入的第一線。因此，Linux核心中的漏洞會產生廣泛的影響，使人們、組織和裝置的安全和隱私面臨風險。由於它主要是用C語言編寫的，而C語言不是記憶體安全的，所以記憶體安全漏洞，如緩衝區溢位和使用後賦值，是一個持續的問題。通過使Linux核心的部分內容用Rust語言編寫成為可能，這是記憶體安全的，我們可以完全消除某些元件的記憶體安全漏洞，比如驅動程式。

當前進展：Google 贊助 且 由 ISRG 組織僱傭 Miguel Ojeda （核心開發），讓他全職從事Rust for Linux和其他安全工作，為期一年。希望能通過讓他全職從事這項工作，為支援數字基礎設施盡一份力。

團隊規模

核心開發：1 ～ 6人。

暫未有其他資訊。

Coreutils

關鍵字：GNU/ Shell/ Rust for Linux

介紹

Coreutils[178] 是GNU Shell 的核心實用程式的 Rust 實現。

程式碼及團隊規模

程式碼量大約為 77000 行 Rust 程式碼。

團隊規模：

• 主力開發：8人
• 社群貢獻：250人

項目週期

項目於2020年底啟動，迭代週期平均一月一個小版本，目前 0.0.6 版本。目前狀態，足以通過 GNOME 啟動 Debian 系統。

Occulum （國內/開源/TEE 庫作業系統）

關鍵字：機密計算/ 可信計算/  TEE / 庫作業系統

Occulum[179] 是螞蟻開源的 TEE 作業系統，也是 CCC 機密計算聯盟中第一個由中國公司發起的開源項目。

Occlum 提供 POSIX 程式設計介面，支援多種主流語言（C/C++, Java, Python, Go, Rust 等），支援多種安全檔案系統。可以說，Occlum 提供了一個相容 Linux 的 Enclave 運行環境，使得機密計算可以輕鬆支援已有的應用，也使得機密應用開發者複用原有開發技能。Occlum 不但在工業界場景中得到了廣泛的應用，而且也在系統頂會 ASPLOS 2020 發表了學術論文，代表了機密計算業界的領先水平。

從架構上來看，Occlum 不但提供基本的類似 Linux 的作業系統能力，而且提供一個類似 Docker 的使用者使用介面，比如這裡的 Occlum build 和 Occlum run 等都跟 docker 的命令類似。

程式碼與團隊規模：

Occulum 程式碼量大約  28000 多行。

團隊規模：

• 主力開發：5人。
• 社群貢獻：22 人。

項目週期

迭代週期是每六週發一個新版。

rCore 和 zCore （國內/ 教育/ 學術/ 開源/ 作業系統）

關鍵字：清華大學/ rCore/ zCore/ 作業系統/ 教學

介紹

rCore[180] 是用 Rust 重新實現的 Linux 核心，誕生於 2018 年，目前已在清華計算機系的作業系統教學實驗中試點應用。

zCore[181] 是用 Rust 語言重新實現的 Zircon （Google Fuchsia OS 的微核心）微核心。它運行在核心態，對外提供與 Zircon 完全相同的系統呼叫，因此能夠運行原生的 Fuchsia 使用者程式。不僅如此，它還可以作為一個普通的使用者程序運行在 Linux 或 macOS 的使用者態，我們一般把這種模式稱為 LibOS 或 User-Mode OS。你甚至無需安裝 QEMU 模擬器，只需裝上 Rust 官方工具鏈，就可以編譯運行體驗 zCore！

一些相關學習資源：

• 下一代 Rust OS：zCore 正式釋出[182]

• 用`Rust`寫作業系統 | 清華 rCore OS 教程介紹[183]

程式碼及團隊規模

rCore 程式碼量大約為  26000 行 Rust 程式碼，zCore 程式碼量大約為 27000 行 Rust 程式碼。

團隊規模：

• 主力開發：3～5人
• 社群貢獻：30 人左右

項目週期

兩個項目都已進入維護期，沒有對外發布版本。

Redox （國外/ 開源/ 作業系統）

關鍵字：作業系統

介紹

Redox是一個用**Rust**[184]語言編寫的類UNIX作業系統 , 它的目標是把Rust語言的創新帶入到一個現代的微核心和全系列的應用程式。Redox 幕後公司應該是 System 76 公司。主要項目放在 GitLab 中。

程式碼及團隊開發

程式碼量目前大約為 134 萬行 Rust 程式碼，算得上是 Rust 生態中重量級項目了。

團隊規模：

• 主力開發：21人
• 社群貢獻：79 人。

項目週期

Redox 從 2016 年開始立項，直到 2017 年 0.3 版本開始，每年釋出一個小版本，到今年已經發布到 0.5 版本。

tockOS （國外/開源/嵌入式實時作業系統）

關鍵字：嵌入式作業系統/實時

介紹

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

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

程式碼及團隊規模

程式碼量大約為 15萬 行 Rust 程式碼。

團隊規模：

• 主力開發：4 人。
• 社群貢獻：123 人。

項目週期

該項目目前已進入維護期。

目前 1.6 版本釋出，以往迭代週期大概是每半年釋出一個小版本。

Theseus (國外/開源/高階嵌入式作業系統/研究項目)

關鍵字：嵌入式作業系統/研究型

介紹

Theseus[187] 是美國萊斯大學多年實驗的結果，也有其他大學參與，比如耶魯大學。它通過減少一個元件對另一個元件持有的狀態來重新設計和改進作業系統的模組化，並利用一種安全的程式語言 Rust，將盡可能多的作業系統責任轉移給編譯器。

Theseus 體現了兩個主要貢獻。

• 一個作業系統結構。其中許多微小的元件具有明確定義的、運行時持久的界限，它們之間的互動不需要彼此持有狀態。
• 一種使用語言級機制實現作業系統本身的內部語言方法。這樣編譯器就可以執行關於作業系統語義的不變性。

Theseus 的結構、內部語言設計和狀態管理以超越現有作品的方式實現了核心作業系統元件的實時演進和故障恢復。

更多資料：《Theseus: an Experiment in Operating System Structure and State Management》[188]

程式碼及團隊規模

程式碼量大約為 56000 行程式碼。

團隊規模：

• 主力開發：1 人。
• 社群貢獻：17人。

項目週期

該項目自 2017 年 3月啟動，目前已經進入維護期。

工具軟體

工具軟體包括使用 Rust 實現的一些 命令列工具、桌面軟體等。

RustDesk （國內/部分開源/遠端桌面軟體）

rustdesk[189]，是一款遠端桌面軟體，開箱即用，無需任何配置，替代TeamViewer和AnyDesk。您完全掌控資料，不用擔心安全問題。rustdesk 是一款商業開源軟體，開源度 90%。

程式碼及團隊規模

程式碼量大約為 35000 行 Rust 程式碼。

團隊規模：

• 主力開發：1人。
• 社群貢獻：8 人。

項目週期

2021 年 3 月 27 釋出 1.1 版本，之前的版本迭代無從知曉。

自此之後基本每月迭代一兩個小版本。

spotify-tui （國外/終端音樂軟體）

關鍵字：Terminal UI/ Spotify

介紹

spotify-tui[190] 是一款終端 Spotify 音樂客戶端，基於 Rust 終端 UI 開發框架 Tui-rs[191] 開發。

程式碼及團隊規模

程式碼量大約為 12000 行 Rust 程式碼。

團隊規模：

• 主力開發：1人。
• 社群貢獻：84 人。

開發週期

已經進入維護期，平均每月一個小版本。

Ripgrep （國外/終端文字搜尋）

關鍵字：文字處理/ 終端工具

介紹

ripgrep[192] 是一個以行為單位的搜尋工具， 它根據提供的 pattern 遞迴地在指定的目錄裡搜尋。它是由 Rust 語言寫成，相較與同類工具，它的特點就是無與倫比地快。ripgrep 目前已經成為 Linux 下最快的文字搜尋工具。

程式碼及團隊規模

程式碼量大約 35000 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人。
• 社群貢獻：287 人。

項目週期

項目於 2016 年開始啟動，在 2018年之前迭代比較頻繁，後面進入穩定維護期，基本一年一個大版本，目前版本為 13.0.0 。

nushell （國外/開源/shell工具）

關鍵字：shell

介紹

NuShell [193] 是使用 Rust 語言編寫的跨 Unix, Windows, macOS 系統的現代 Shell 程式。

NuShell 不像傳統的 Unix Shell，它從 PowerShell 汲取靈感，將每個命令產生的結果視作具有結構的物件，而不是傳統的原始位元組。但和 PowerShell 相比，它的速度要快得多。

NuShell 的特色在於結構化資料以及類似 SQL 的二維表操作， 在處理大量結構化資料時具有一定優勢，幾乎相當於一個針對本地檔案、資料的 SQL 解析器。不過其缺少流程控制語句的特點，讓它難以勝任邏輯化的系統管理工作。

程式碼及團隊規模

程式碼量大約為 10萬行 Rust 程式碼。

團隊規模：

• 主力開發：2人。
• 社群貢獻：231 人。

項目週期

該項目於 2019年 5月啟動，迭代週期為每個月一個小版本，目前為 0.32.0 版本。

alacritty (國外/開源/模擬終端)

關鍵字：模擬終端/OpenGL

介紹

**Alacritty **[194]是一個免費的開源，快速，跨平臺的終端模擬器，它使用GPU （ 圖形處理單元 ）進行渲染，實現了Linux[195]中許多其他終端模擬器[196]所不具備的某些優化。

Alacritty專注於簡單和效能兩個目標。效能目標意味著，它應該比任何其他可用的終端模擬器快。簡單性目標意味著，它不支援Linux中的選項卡或分割 （可以由其他終端多路複用器 - tmux[197]輕鬆提供）等功能。

效能上已經秒殺Linux 上同類工具了。

程式碼及團隊規模

程式碼量大約為 22000 行 Rust 程式碼。

團隊規模：

• 主力開發：2人
• 社群貢獻：330人。

項目週期

項目啟動於 2016 年，目前迭代週期平均每三個月釋出一個新的小版本。目前版本號 0.8.0。雖然還未穩定1.0版本，但已經成為很多人日常開發工具了。

Gitui (國外/開源/Git終端UI)

關鍵字：Git/ Terminal UI

介紹

Gitui[198] 是一個速度很快的 Git 終端介面。

程式碼及團隊規模

程式碼量大約為 29000 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人。
• 社群貢獻：42 人。

項目週期

項目於 2020 年3 月 15日啟動，迭代週期平均為每兩週一個小版本釋出。目前 0.16.1 版本。

其他優秀的終端工具

• exa[199]，Rust 重寫 ls  工具。
• bottom[200]，Rust 重寫 Top 工具。
• starship[201] 超級快、支援各種訂製的極簡命令列提示符，支援任意 shell
• bat[202] 支援更多特性的 cat 克隆
• delta[203] git、diff 輸出檢視器
• zoxide[204] 更快捷地瀏覽檔案系統
• fd[205]簡單、快速、使用者友好的 find 替代品
• tealdeer[206]  眾人一起編寫的終端命令速查卡

機器學習

機器學習領域包括，基於 Rust 實現的機器學習框架、科學計算庫等等。

linfa （國外/開源/機器學習工具包）

關鍵字：scikit-learn/ sklearn/ 基礎工具包

介紹

Linfa[207] 是一個 Rust 實現的 類似於 python  scikit-learn 的庫，旨在提供一個全面的工具包，可以使用 Rust 構建機器學習應用程式。該團隊還創建了 Rust-ML 組織。

「

scikit-learn，又寫作sklearn，是一個開源的基於python語言的機器學習工具包。它通過NumPy, SciPy和Matplotlib等python數值計算的庫實現高效的演算法應用，並且涵蓋了幾乎所有主流機器學習演算法。

更多資料：Rust 機器學習之書[208]

程式碼及團隊規模

程式碼量大約為 23000 行 Rust 程式碼。

團隊規模：

• 主力開發：6人
• 社群貢獻：12人

項目週期

該項目 2018年就立項了，但是正式動工是 2020年10月，2021年進入迭代期。基本每月一個小版本，最近的版本在4月份釋出的，0.4.0版本。項目開發狀態還是比較活躍的。

tokenizers (國外/開源/自然語言處理分詞庫)

關鍵字：自然語言處理/ 分詞庫

介紹

tokenizers[209] 是 Hugging Face 公司開源的一款 Rust 實現的分詞庫。

Hugging Face  是一家總部位於美國紐約的聊天機器人初創服務商。該公司在 NLP界鼎鼎大名，三月份剛剛完成4000萬美元B輪融資。在GitHub上釋出了開源 NLP 庫 Transformers。

基於深度學習的現代 NLP 管道中的瓶頸之一就是tokenization，尤其是通用性強且獨立於框架的實現。

所以，該分詞器的核心是用Rust編寫的，並且存在Node和Python的繫結。提供當今最常用的分詞器的實現，重點是效能和通用性。

特點：

• 使用當今最常用的分詞器（tokenize），訓練新的詞彙並進行標記。
• 由於採用Rust實現，速度極快（包括訓練和標記化）。在伺服器的CPU上對一GB的文字進行標記化只需不到20秒。
• 易於使用，但也非常通用。
• 為研究和生產而設計。
• 正則化帶有對齊性跟蹤。總是可以得到與給定標記相對應的原始句子的部分。
• 做所有的預處理。截斷、填充、新增你的模型需要的特殊標記。

程式碼及團隊規模

程式碼量大約 28000 行 Rust 程式碼。佔總項目的 68%，該項目還有部分 Python 程式碼。

項目週期

該項目自 2019 年10月開始啟動，迭代週期平均為每月一個小版本，目前版本為 Python V0.10.3。

tch-rs (國外/開源/PyTorch 繫結)

關鍵字：PyTorch/ cpp api 繫結

介紹

tch-rs[210]是Pytorch的Cpp API的生鏽繫結。Tch Crate的目標是圍繞 Cpp Pytorch API 提供一些薄的包裝器。它旨在儘可能接近原始的Cpp API。然後可以在此之上開發更加慣用的 Rust 繫結。

程式碼及團隊規模

程式碼量大約為 58000 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人
• 社群貢獻：36 人

項目週期

該項目從 2019 年 2月啟動，截止到今天，還沒有正式釋出任何版本。目前還在活躍維護中，但可能是 個人項目。

ndarray （國外/開源/科學計算）

關鍵字：科學計算/ N 維陣列

ndarray[211] 是一個由Rust官方團隊中資深科學計算專家bluss開發的開源項目，實現了基於rust的矩陣和線性運算。目標是在Rust中建立類似於numpy和openblas的科學計算社群。它是機器視覺、資料探勘、生物資訊等多類科學計算庫的基礎，社群中的主要使用者為一些相關技術的高校或者研究所。

目前 華為 也在深度參與該基礎庫的研發，參見 華為 | Rust 科學計算多維陣列運算庫的分析與實踐[212]。

另外還有線性代數相關庫：ndarray-linalg[213] 。

程式碼及團隊規模

程式碼量大約為 29000 行 Rust 程式碼。

團隊規模：

• 主力開發：1人
• 社群貢獻：57 人

項目週期

該項目自 2015 年11 月啟動，平均每半年 1 ～ 2 個小版本釋出。

TVM-rs （國外/開源/ TVM rust 繫結）

關鍵字：Apache/ TVM

介紹

tvm-rs[214] 是 TVM 的 Rust 繫結。

TVM 是由華盛頓大學在讀博士陳天奇等人提出的深度學習自動程式碼生成方法，去年 8 月機器之心曾對其進行過簡要介紹。該技術能自動為大多數計算硬體生成可部署優化程式碼，其效能可與當前最優的供應商提供的優化計算庫相比，且可以適應新型專用加速器後端。

簡單來說，TVM可以稱為許多工具集的集合，其中這些工具可以組合起來使用，來實現我們的一些神經網路的加速和部署功能。這也是為什麼叫做TVM Stack了。TVM的使用途徑很廣，幾乎可以支援市面上大部分的神經網路權重框架(ONNX、TF、Caffe2等)，也幾乎可以部署在任何的平臺，例如Windows、Linux、Mac、ARM等等。

程式碼及團隊規模

程式碼量大約為 1 萬多行。

團隊規模：

• 主力開發：3人
• 社群貢獻：7～10人

項目週期

不定時維護。

Neuronika （國外/開源/機器學習框架）

關鍵字：PyTorch/ 機器學習框架

介紹

Neuronika[215] 是一個用 Rust 編寫的機器學習框架，與 PyTorch 類似，現已實現最常見的層元件（dense 層、dropout 層等），速度堪比 PyTorch。其構建重點在於易用性、快速原型開發和高效效能。

Neuronika 是由 Francesco Iannelli 等人開發，他們現在是電腦科學的碩士生。該框架提供了自動分化和動態神經網路，非常像 Pytorch。目前已經實現了最常見的層元件，如 dense 層、dropout 層、GRU、LSTM 和 1d-2d-3d CNN，然而，缺少池化層等等。Neuronika 還提供了損失函數、優化器、計算圖、張量和資料實用程式。

速度方面，項目作者表示 Neuronika 的表現可與 PyTorch 媲美。你可以對它進行基準測試。但目前還不能支援 GPU。想要進行基準測試，可以參考測試文件。

Neuronika 的核心機制是一種叫做反向模式自動分化機制（ reverse-mode automatic differentiation），這種機制允許使用者在改變動態神經網路時可以輕鬆實現，沒有任何開銷，可通過 API 運行。

程式碼及團隊規模

程式碼量大約為 26000 行 Rust 程式碼。

團隊規模：

• 主力開發：2 人
• 社群貢獻：0 人

新項目，目前還未有人貢獻。

項目週期

還未迭代出初始版本，但開發動態比較活躍。

其他

• TensorFlow-rs[216]，TensorFlow Rust 繫結，2021 年維護狀態，不太活躍。
• Whatlang[217]，基於 Rust 實現的 自然語言 識別項目。
• Awesome-Rust-MachineLearning[218]，Rust 機器學習相關生態項目列表。

遊戲

遊戲領域包括，使用 Rust 製作的遊戲、Rust 遊戲引擎、Rust 遊戲生態建設等。

veloren (國外/沙盒遊戲/開源)

關鍵字：沙盒遊戲/ 我的世界

介紹

Veloren[219] 是用 Rust 開發的開源免費多玩家 voxel RPG。它的靈感來自諸如《魔方世界》，《塞爾達傳說：曠野之息》，《矮人要塞》和《我的世界》等遊戲。支援多人、單人，可以在Windows、Mac、Linux上游玩。點選 官網[220] 瞭解更多。

Veloren 應該是最早使用 Rust 的項目了，該項目在 2013 年就開始使用 Rust 開發，當時 Rust 還未 1.0 。截止到2021年的今天，該項目還保持著活躍更新。

Veloren 的創始人，也是 Rust 官方遊戲開發組成員之一。

程式碼及團隊規模

程式碼量大約為 20 萬行 Rust 程式碼。

團隊規模：

• 主力開發：15 人。
• 社群貢獻：175 人。

項目週期

項目迭代週期平均每三月發一個小版本。目前是 0.10.0 版。

A / B Street (國外/開源/街景交通探索遊戲)

關鍵字：

A / B Street[221] 是一個遊戲，探索城市對駕駛員，騎自行車者，過境使用者和行人的運動的小變化。

遊戲最終目標是讓玩家成為調整西雅圖（預設）基礎設施的真正建議，A/B Street 使用OpenStreetMap[222] ，所以遊戲可以是世界上任何一個地方。A / B街當然是一個遊戲，使用簡化的交通建模方法，所以城市政府仍然必須使用現有方法來評估提案。A / B Street旨在作為與互動式視覺化傳達想法的對話啟動器和工具，或者給城市規劃專家做參考。

程式碼量及團隊規模

程式碼量大約為 10 萬 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人
• 社群貢獻：24 人

項目週期

項目從2018年3月11 啟動，截止到當前 2021年6月，一直高速迭代。迭代週期平均是每週一個小版本。

Embark 公司 與 Rust 遊戲生態

關鍵字：Rust Game Ecosystem

介紹

Embark 公司是 Johan Andersson （遊戲界知名人物）創建的遊戲工作室，在創建之初就選擇 Rust 作為主要語言。

「

我們相信，通過與社群公開分享我們的工作、問題和想法，我們將創造更多的合作和討論機會，使我們走向Rust和整個遊戲行業的偉大未來。-- Johan Andersson (@repi), CTO, Embark

在Embark，我們一直用 Rust 從頭開始構建自己的遊戲引擎。我們在RLSL原型的內部開發方面擁有先前的經驗，我們擁有一支由出色的渲染工程師組成的團隊，他們熟悉遊戲，遊戲引擎和其他行業中當今著色器語言的問題。因此，我們認為我們處於解決這一問題的獨特位置。

我們希望使用一種出色的語言簡化我們自己的內部開發，建立一個開源圖形社群和生態系統，促進GPU和CPU之間的程式碼共享，最重要的是-使我們（未來的）使用者和其他開發人員擁有更多快速創建引人入勝的體驗。

創建 Rust 遊戲生態並非口號，Embark 公司也加入了 Rust 遊戲工作組，並且創建了一系列打造 Rust 遊戲生態的庫。

這些庫都羅列在 rust-ecosystem[223] 倉庫中。

其中最重要的一個庫是 rust-gpu[250]，旨在讓 Rust 成為建立GPU程式碼的一流語言和生態系統。

使用Rust的願望 為GPU編寫程式 不僅源於安全功能和高效能， 而且還需要獲得與軟體包和模組一起使用的現代工具，以提高開發過程的效率。

歷史上，在遊戲中，GPU程式設計是通過編寫HLSL完成的 或在較小程度上包括GLSL。這些是簡單的程式語言，這些年來隨著渲染API一起發展。

但是，隨著遊戲引擎的發展，這些語言還沒有提供處理大型程式碼庫的機制，總的來說， 與其他程式語言相比，它們已經落後了。

雖然一般來說，兩種語言都有更好的替代方法，但是都無法代替HLSL或GLSL。

是因為它們被提供程式阻止，還是因為它們不受支援 與傳統的圖形管道。這樣的示例包括CUDA和OpenCL。儘管已嘗試在此空間中創建語言，但沒有一個在gamedev社群中獲得明顯的吸引力。

Rust GPU繼續根據RLSL項目開發思想，其中嘗試為SPIR-V通用著色器中介軟體創建Rust編譯器，該編譯器在Vulkan API中提出，並在OpenGL 4.6中得到支援。在目前的開發階段，Rust GPU已經允許您運行簡單的圖形著色器並編譯Rust基本標準庫的重要部分。同時，該項目還沒有為廣泛使用做好準備，例如，著色器尚不支援迴圈。

基於Rust語言的程式碼，形成了SPIR-V著色器的表示形式，為此開發了一個Rust編譯器的特殊後端，該類後端類似於用來編譯成表示形式的Cranelift程式碼生成器WebAssembly。

當前的方法是支援Vulkan圖形API和SPIR-V檢視， 但是計劃在未來的DXIL（DirectX）和WGSL（WebGPU）著色器檢視中使用生成器。基於Cargo和crates.io，正在開發工具來開發和釋出帶有SPIR-V格式的著色器的程式包。

目前還屬於非常早期，以平均每週一個小版本迭代，現在釋出 0.3 版。主力開發大約六人，社群貢獻 35 人。

Bevy （國外/遊戲引擎/開源）

關鍵字：遊戲引擎/ ECS

介紹

Bevy 是一個基於 Rust 實現的 資料驅動遊戲引擎。

「

Bevy完整實踐了時下比較熱門的data-driven開發理念， 也就是ECS模式。相比於其他架構比較老的開源引擎，比如Godot等，Bevy有一整套的從造輪子到遊戲開發落地的ECS開發模式。而和商業引擎相比，Bevy的歷史包袱也很少，不用像unity的DOTS開發一樣還需要相容傳統的GameObject模式。此外，得益於Rust語言強大的表達能力，整個引擎在介面上看起來比用C++造的那些data-driven的輪子要簡潔明瞭的多。-- 《安利一個Rust Game Engine：Bevy--ECS部分》[251]

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

程式碼及團隊模式

程式碼量大約為 65000 行 Rust 程式碼。

團隊規模：

• 主力開發：1 人
• 社群貢獻：244 人

項目週期

項目啟動自 2019 年 11 月 10 號，目前釋出 0.5 版本，還處於高速迭代器。Bevy 項目也經歷過一次大的重構，重構了底層 ECS 系統。

其他動態

• https://gamedev.rs/[252]  是 Rust 遊戲工作組的官方站點，定期釋出 Rust 在遊戲生態中的動態。

客戶端開發

飛書 App （國內/商業）

關鍵字：lark/ 位元組跳動

介紹

位元組跳動旗下 飛書（lark）App ，應該屬於國內最大的 Rust 開發團隊，全職寫 Rust 的開發人員大約在 30 ～ 60 人。

飛書在 客戶端跨平臺元件中使用 Rust ，程式碼量據說超過 55 萬行程式碼 （包括測試和生成程式碼）。

其他資訊目前不詳細。

飛書團隊還開源了幾個 Rust 項目，可以在其 GitHub 倉庫[253]中查閱。

區塊鏈/數字貨幣

區塊鏈/數字貨幣領域包括，區塊鏈基礎設施、數字貨幣項目等。

Diem (國外/開源/Libra/ 超主權貨幣)

關鍵字：libra/ Facebook

介紹

Diem[254] 前身是 Libra，其使命是建立一套簡單的、無國界的貨幣和為數十億人服務的金融基礎設施。他們努力打造一個新的去中心化區塊鏈、一種低波動性加密貨幣和一個智慧合約平臺的計劃，以期為負責任的金融服務創新開創新的機遇。

他們認為，應該讓更多人享有獲得金融服務和廉價資本的權利，每個人都享有控制自己合法勞動成果的固有權利。他們相信，開放、即時和低成本的全球性貨幣流動將為世界創造巨大的經濟機遇和商業價值，並堅信人們將會越來越信任分散化的管理形式。全球貨幣和金融基礎設施應該作為一種公共產品來設計和管理。所有人都有責任幫助推進金融普惠，支援遵守網路道德規範的使用者，並持續維護這個生態系統的完整性。

最新狀態：Facebook旗下數字貨幣項目Diem放棄申請瑞士支付牌照：專注美國市場 （2021年05月13日 ）。

程式碼及團隊規模

程式碼量大約為 30 萬 行 Rust 程式碼。

團隊規模：

• 主力開發：5～ 20 人
• 社群貢獻：150 人

項目週期

平均每月一個小版本，目前主框架 1.2.0 版，sdk 0.0.2 版。

Substrate （國外/ 開源/ 區塊鏈框架）

關鍵字：parity/substrate

介紹

Substrate[255] 是Parity Polkadot 旗下的項目。Polkadot 是基於 Substrate 構建的。

Substrate 框架被稱為下一代區塊鏈框架，類似於Java的Spring、Python的Django，只不過後者創建的是網站，前者創建的是區塊鏈。它由Parity團隊基於Rust語言開發而成，是一個開箱即用的區塊鏈構造器。基於Substrate創建區塊鏈可以讓開發者專注於業務需求，不需從頭實現底層的P2P網路和共識邏輯。

程式碼及團隊規模

程式碼量大約為 35 萬行 Rust 程式碼。

團隊規模：

• 主力開發：4～10人
• 社群貢獻：243 人

項目週期

Substrate 經過兩次大的版本迭代，已發展到了 V3.0 版。目前迭代週期平均每月一個小版本。

Nervos CKB （國內/ 區塊鏈公鏈）

關鍵字：nervos/ ckb/ cita

介紹

Nervos Network 是一個開源的公鏈生態，包含以區塊鏈技術為核心、相互相容的一組分層協議，來解決區塊鏈可擴展性上的困境。

Nervos CKB[256]（Common Knowledge Base 共同知識庫）是一個無需許可的公有區塊鏈，在區塊鏈中，這裡提到的共同知識庫通常指的是經過全球節點共同驗證並確認的狀態。和位元幣類似，Nervos CKB 是一個狀態驗證系統。由杭州祕猿科技研發。

祕猿也算國內 Rust 開發人員眾多的公司之一，Rust 全職開發大約是 30 + 人。

程式碼量及團隊規模

單 ckb 項目程式碼量，大約 11 萬行 Rust 程式碼。

團隊規模：

• 主力開發：6 ～ 8 人（單ckb項目）
• 社群貢獻：22 人

項目週期

開發週期大約每週一個小版本。

其他區塊鏈項目

• Near[257]
• Solana[258]

其他 Rust 正在革新的領域

• 機器人：

• zenoh[259] ，zenoh 將動態資料、使用中資料、靜態資料與計算整合。它巧妙地將傳統的釋出/訂閱與地理上分散的儲存、查詢和計算融合，同時保有遠勝任何主流堆棧的時間和空間效率。zenoh 可作為 ROS2 中介軟體 DDS 替代品，也可以和 DDS 無縫整合。

• 航天航空：

• 紐西蘭 公司 Rocket Lab [260]是小型衛星發射領域的全球領導者，和 NASA 、xSpace 都是合作伙伴。團隊有500人，而且每週都在增加。目前在使用 Rust 。
• 非官方 航空航天工作組 AeroRust[261] 創建了 Are we **in space** yet?[262] 網站，跟蹤 Rust 在航空航天領域的開源項目。

• 汽車/自動駕駛：

• erdos[263]，用於構建自動駕駛汽車和機器人應用的資料流系統。

• 程式語言：

• Rust[264]，Rust 語言早已實現了自舉，算得上是世界上最大的 Rust 項目之一了。其程式碼量大約 179 萬行 Rust 程式碼。
• langs-in-rust[265] 這個網站羅列了 幾十種 用 Rust 實現的新程式語言。其中也不乏優秀之作。比如 Gleam[266] / Dyon[267] / Koto[268]

• 藝術：

• nannou[269]，旨在讓藝術家創作自己的藝術。在德國 mindbuffer[270] 公司就是基於 nannou 和 koto 來創建實體藝術項目：使用486步進電機，86,000個LED和5通道顆粒式合成引擎，創建可以變換形狀絢麗多彩的電子藝術品[271]。

• VR 領域：

• makepad[272]，是一個 VR，Web和本機渲染UI框架 和 IDE，基於 Rust 和 WebAssembly （WebGL） 技術。作者是 Cloud9 IDE 的創始人。該項目也包含白皮書[273]，闡述了它的願景。

盤點在生產環境使用 Rust 的公司

國內

華為

「

可信程式設計的願景之旅，才剛剛開始。我們希望與 Rust 社群，以及即將成立的 Rust 基金會合作，為電信軟體行業帶來一場平穩的革命。

華為於 2021 年加入 Rust 基金會，旨在為 Rust 在全球推廣和發展做貢獻。目前在一些開源項目和內部試點項目使用了 Rust ，以及為 Rust 生態做了一些貢獻。目前正在為大規模使用 Rust 做準備。

華為也是 Rust Conf China 2020 戰略級贊助商。

PingCAP 及其 客戶

PingCAP 公司創造的 分散式資料庫 TiDB，底層TiKV分散式儲存是基於 Rust 實現的。

TiDB 現已被 **1500** 多家不同行業的領先企業應用在實際生產環境[274]。客戶包括：中國移動/ 中通快遞/ 伴魚/ 知乎/ 網易遊戲/ 美團/ 京東雲/ 360雲/ 今日頭條 等等公司。

PingCAP 也是 Rust Conf China 2020 銀牌贊助商。

阿里/螞蟻集團

阿里雲/ 釘釘團隊，以及螞蟻集團 機密計算 和 資料庫團隊，都在使用 Rust 。

位元組跳動

位元組跳動 飛書團隊 使用 Rust 進行跨平臺客戶端元件開發。

位元組跳動/飛書 也是 Rust Conf China 2020 鑽石贊助商。

知乎

知乎搜尋引擎團隊在使用 Rust 。

收錢吧

上海收錢吧團隊在生產環境使用 Rust 做訊息佇列服務。

吉利集團

吉利集團數字科技板塊在使用 Rust 構建區塊鏈。

上海息未資訊科技

上海息未資訊科技有限公司專注於航天及航空訓練裝備的研發生產，是由國內頂級基金投資的科技企業，主要服務於中國航天、軍隊以及航空公司。其公司部分產品使用 Rust 。

杭州祕猿科技

CBK 公鏈項目就是該公司產品。還有其兄弟公司 溪塔 也是 Rust 生產級使用者。

祕猿和溪塔同是 Rust China Conf 2020 金牌贊助商。

國內其他區塊鏈公司

Bitfrost

Bitfrost 也是區塊鏈項目，為 Staking 提供流動性的跨鏈網路。Rust China Conf 2020 銀牌贊助商。

達爾文網路

達爾文網路是基於Substrate開發的去中心化橋接網路，也是區塊鏈行業。Rust China Conf 2020 銀牌贊助商。

還有很多其他區塊鏈公司，都在使用 Rust ，這裡就不一一羅列了。

豆瓣

豆瓣使用了 Rust 開源庫 Vector ，應該屬於被動使用 Rust 。其他團隊是否在其他項目使用 Rust 猶未可知。

國外

Google

Google Fuchsia OS 內 Rust 使用量大約為 137 萬行 Rust 程式碼，算的上是 Rust 生態圈內除 Rust  之外第二大 Rust 項目了。

並且 Google 極力支援 Rust for Linux 項目，還出資金贊助了核心開發。

Google 也是 Rust 基金會成員之一。

「

Android[275]：「在過去的 18 個月裡，我們一直在為 Android 開源項目新增對 Rust 的支援。我們有幾個早期採用 Rust 開發的項目，我們將在未來幾個月內分享。將 Rust 擴展到更多作業系統，是我們的一個多年項目。」

微軟

Rust 基金會成員之一。目前 Windwos 已經全面支援 Rust 開發。

「

有沒有注意到 VS Code 的搜尋速度有多快？原因是 VS Code 正在使用 `ripgrep`[276] 來增強它的搜尋能力[277]  。

AWS

Rust 基金會成員之一。AWS 應該是最早支援 Rust 社群的公司了，連續幾年贊助 Rust Conf。

「

在 AWS，我們喜歡 Rust，因為它幫助 AWS 編寫高效能、安全的基礎設施級網路和其他系統軟體。我們使用 Rust 提供的服務產品有很多，比如 Amazon 簡單儲存服務（Amazon S3）、Amazon 彈性計算雲（Amazon EC2）、Amazon CloudFront、Amazon Route 53 等等。最近我們推出了 Bottlerocket，這是一個基於 Linux 的容器作業系統，也是用 Rust 開發的。

Facebook

Rust 基金會成員之一。Facebook 內部 Rust 項目綜合起來程式碼已超 百萬行。著名的項目是 Diem 及其 MOVE 語言。

Facebook 目前也擁有一個團隊，專門為 Rust 編譯器和庫做貢獻。

Mozilla

Rust 語言的誕生之地。Servo 瀏覽器核心項目使用 Rust 開發，程式碼量大約為 30萬 行 。

Apple

蘋果在招聘公告中寫到：「我們構建的系統的效能和安全性至關重要。目前使用非同步 I/O 和執行緒來分配工作負載，直接與底層 Linux 核心介面進行互動。首次成功使用 Rust 之後，我們正在將已建立的程式碼庫從 C 遷移到 Rust，並計劃未來主要使用 Rust 構建新功能。」

蘋果目前沒有加入 Rust 基金會。

1Password

「

我們在 1Password 的生產環境中，使用 Rust 已有幾年了。我們的 Windows 團隊是這項工作的領跑者，Windows 中所用的 1Password 7，大約 70% 都是用 Rust 開發的。在 2019 年底，我們還將 1Password Brain（驅動瀏覽器填充邏輯的引擎）從 Go 移植到了 Rust。這樣，我們就可以在瀏覽器擴展中，發揮將 Rust 程式部署到 WebAssembly 應用的效能優勢。

Cloudflare

「

隨著我們 Rust 開發經驗的增長，Rust 語言在另外兩個方面顯示出了優勢：作為一種具有強大記憶體安全性語言，它是邊緣計算的一個絕好選擇；作為一種具有極大熱情的語言，它成為一種流行於元件重新開發（de novo）的語言。

Discord

「

當開始一個新的項目或元件時，我們首先考慮使用 Rust。當然，我們只在適合的地方使用。除了效能之外，Rust 對工程團隊也有很多優勢。例如，它的類型安全性和借用/引用檢查器，使重構程式碼變得非常容易。此外，Rust 的生態系統和工具都非常出色，背後有著巨大的動力。

IBM

「

IBM 的一個團隊使用 WebAssembly 和 Rust，實現了難以置信的效能改進。

Dropbox

「

我們用 Rust 開發了 Nucleus！Rust 幫助我們團隊力量倍增，選擇 Rust 是我們做出的最好決定之一。Rust 的人機工程學和正確原則，不僅有助於我們馴服 sync 的複雜性。而且，我們可以在類型系統中，對系統進行復雜的不變數編碼，並讓編譯器為我們檢查它們。

npm

「

npm 的第一個 Rust 程式，在一年半的生產環境中，沒有發生任何警報。‘我對 Rust 最大的讚美，是它很無聊’，Dickinson說，‘這是一個令人驚奇的讚美’。部署新的 Rust 服務的過程是直接的，很快，他們就能夠忘記這項 Rust 服務，因為它只引起很少的操作問題。

OneSignal

「

就在這個月，我們突破了每天傳送 70億 條通知的門檻，並創下了每秒 175 萬條的記錄。

Qovery

「

隨著公司意識到雲端計算的好處，Rust 的勢頭就越來越強勁。Dropbox 使用 Rust 重寫了它的一些核心系統，而 Mozilla 使用 Rust 構建了 Firefox 瀏覽器引擎，展示了 Rust 強大的優勢。在 Qovery，我們相信 Rust 能夠雲構建的未來。

Astropad

「

有了 Rust，我們將擁有一個高效能、可移植的平臺，可以輕鬆地在 Mac、iOS、Linux、Android，以及 Windows 上運行。這不僅極大地擴大了我們潛在的市場規模，而且還看到了我們的 LIQUID 技術的許多有趣的新用途。我們有信心用以強大的程式碼、更好的產品和對 Astropad 未來的樂觀展望，以完成我們的 Rust 之旅。

Coursera

「

我們在增強的 Docker 容器中，高效、可靠、安全地為提交的作業評分。雖然我們將叢集排程到 Amazon EC2 容器服務（ECS）上，但許多程式之間協同工作，是用 Rust 開發的。

三星

「

我們想向 Rust 語言的 5 個核心團隊、Mozilla，以及 Rust 語言生態系統中眾多軟體包的貢獻者們公開道謝：我們正在利用 Rust 開發新的更新客戶端和伺服器，以及其他一些軟體的主幹，並希望隨著時間的推移，繼續擴大我們對該語言的使用。」

System76

「

像我們今天的所有項目一樣，它是用 Rust 編寫的，並且遵循當前的最佳實踐。該項目被配置為一個工作區，核心 crate 提供了一個通用庫，用於從多個固件服務中發現和管理固件。支援 fwupd 和 system76-firmware。

Clever Cloud

「

對我們來說，這些好處有力地證明了 Rust 是生產平臺的可靠構建塊。這是一段我們不必擔心的程式碼，它將使其它服務能夠安全地運行。

Rapid7

「

我們在 Rust 部署中，看到的主要加速點是，不同平臺上的部署工具，能夠很容易地適應該語言。代理開發人員，能夠很快地學習該語言，並開發與託管運行時的整合。

Figma

「

雖然我們有一些挫折，但我想強調的是，我們在 Rust 方面的經驗，總體上是非常積極的。這是一個非常有前途的項目，我們擁有堅實的核心和健康的社群。

Fly.io

「

我們基礎設施中的每臺伺服器，都在運行一個名為 fly-proxy 的基於信任的代理。此代理負責接受客戶端連線、將其與客戶應用程式匹配、應用處理程式（例如：TLS終止）以及伺服器之間的回程處理。

Everlane

「

Rust 給予我們鍛造性。這項服務已經在生產環境運行 4 個月了，它平均每秒處理 40 個請求，響應時間為 10ms。它的記憶體使用量很少超過 100MB。

還有很多公司，可以在 Rust 官網裡看到介紹 ：Rust Production users[278]

參考資料

☞Windows 11 正式官宣：全新 UI、支援安卓 App、應用商店 0 抽成！
☞React 毀了 Web 開發！
☞防毒軟體 McAfee 創始人獄中身亡，75 年傳奇人生畫下句號