2021 年 Rust 生態(tài)調(diào)研報告 | 星辰大海 【上篇】
文前
在完成本篇報告之后，我得出一個觀點：Rust 的出現(xiàn)并不是要你去用它重寫一切，而是希望你可以用它創(chuàng)造新的未來。當(dāng)然這只是我個人觀點，不代表任何人任何機(jī)構(gòu)和公司。如果您有不同觀點，歡迎探討。
本次報告的所有內(nèi)容都來自于互聯(lián)網(wǎng)公開信息，如有錯誤或不宜在本報告中提及的內(nèi)容，請及時告知。
大綱
Rust Project 自身狀態(tài)
Rust 在各個領(lǐng)域中的應(yīng)用狀態(tài)和趨勢
Rust 職業(yè)崗位分布
Rust 語言在高校教育的普及狀態(tài)
Rust Project 自身狀態(tài)
截止 2021年底，距離 Rust 語言2015年5月15日正式發(fā)布已經(jīng)長達(dá)六年半的時間。在這六年半的時間內(nèi)，Rust 每隔三年發(fā)布一個大版本，叫做 Edition，中文翻譯為版次。
版次這個翻譯來自于書籍出版術(shù)語。比如《Rust 編程之道》第一版、第二版 等。
版次（Edition）的意義
版次（edition）的引入主要是為了 Rust 能在發(fā)展過程中方便地引入一些不向后兼容的特性，而不會影響之前的代碼。比如 Rust 2018 edition中沒有 async / await 關(guān)鍵字，但是在 2021 editon 中引入了 async/await 關(guān)鍵字，這樣就避免破壞舊代碼中 let async = 1;這樣的寫法。版次和語義化版本是正交的概念。
Rust 發(fā)布的每個版次都有其核心主題意義：
2015 Edition：主題是 「穩(wěn)定性（Stability）」。2015 edition 代表 Rust 語言 1.0 將趨于穩(wěn)定。在 1.0 之前 Rust 每天都在變化，而 1.0 之后則意味著團(tuán)隊會致力于向后兼容，這樣開發(fā)者才能穩(wěn)定地使用 Rust 構(gòu)建項目。版次的概念其實在2017年才引入，所以將 2015年正式發(fā)布之前的語義版本號，即 1.0 之前，都?xì)w為 2015 edition。
2018 Edition：主題是 「生產(chǎn)力（Productivity）」。2018 edition 中引入的內(nèi)容大部分是向后兼容的，即，在2015 中可以使用其中一些特性，比如對借用檢查的改進(jìn)NLL。但是對模塊系統(tǒng)的改進(jìn)則只能用于 2018 edition 中。2018 eidtion 既然是以生產(chǎn)力為主題，那么特性的優(yōu)先級都會優(yōu)先服務(wù)于這個主題。
2021 Edition：主題是「成熟（Mature）」。2021 edition 并沒有引入太多新特性，而是清理了一些技術(shù)債務(wù)，比如持續(xù)對 Rust 編譯器進(jìn)行重構(gòu)和改進(jìn)，包括內(nèi)部使用的新的 trait 系統(tǒng)chalk 和 query 系統(tǒng)（開源版本：https://github.com/nikomatsakis/salsa）。另外還處理了一些向后兼容的問題，以及持續(xù)投入一些影響未來發(fā)展的關(guān)鍵特性，比如 常量泛型、泛型關(guān)聯(lián)類型等。
Rust Edition 現(xiàn)在已經(jīng)確定了，每三年發(fā)布一個版次。這就意味著 Rust 每三年都會圍繞一個引領(lǐng) Rust 發(fā)展的主題。
2024 Edition 展望
2024 Edition：主題也許是「廣泛應(yīng)用」。
2021 年 2 月 9 號，Rust 基金會宣布成立。華為、AWS、Google、微軟、Mozilla、Facebook 等科技行業(yè)領(lǐng)軍巨頭加入 Rust 基金會，成為白金成員，以致力于在全球范圍內(nèi)推廣和發(fā)展 Rust 語言。
隨后，ARM 、AUTOMATA、1PASSword、豐田汽車、動視、Knoldus[2] 、Tangram[3] 等各個領(lǐng)域中對未來充滿野心的公司都加入了基金會，為推動 Rust 做貢獻(xiàn)。
最近 Rust 基金會又推選 在非營利組織有十五年經(jīng)驗的 Rebecca 稱為了 基金會的執(zhí)行董事（ED）和CEO。相信在 Rust 基金會的領(lǐng)導(dǎo)下， Rust 會有廣泛的應(yīng)用前景。
Rust Project 機(jī)遇與挑戰(zhàn)
Rust 語言是完全開源的，它也是世界上最大的開源社區(qū)組織。由不同職責(zé)的團(tuán)隊和工作組共同協(xié)作。具體可以在 Rust 官網(wǎng)[4]看到相關(guān)信息。目前擁有 3539 個貢獻(xiàn)者。
截止目前，crates.io [5]上面 crates 的下載總量達(dá)到 11,012,362,794 次，即 110 億次。
我們可以通過這些指標(biāo)來評判一下 Rust 的成熟度。
用戶數(shù)：Rust 連續(xù)六年是用戶最受歡迎的語言，但實際用戶數(shù)，可以從 TIOBE 編程語言排行榜中看出來，截止 2021年11月，Rust 排名 29 ，流行度是 0.54% 。任何沒有進(jìn)入 TIOBE 榜單前20的語言，其實都還需要進(jìn)行營銷和宣傳，這意味著 Rust 依舊屬于小眾語言。
貢獻(xiàn)者數(shù)量。Rust 貢獻(xiàn)者數(shù)量截止目前為 3539 個。我們對比一下Github開源的其他語言：流行的 Go 語言目前貢獻(xiàn)者是 1758個；Kotlin 目前的貢獻(xiàn)者是 516 個?？匆幌铝餍械目蚣?nbsp;Rails 的貢獻(xiàn)者是 4379個。相對而言，Rust 語言貢獻(xiàn)者是相當(dāng)多的。
錯誤修復(fù)/補(bǔ)丁頻率。根據(jù) Github issues 相關(guān)數(shù)據(jù)， Rust 目前肉眼可見每小時平均修復(fù)一個 issue 問題。從 2010年 6月17號 Rust 創(chuàng)始人 Graydon 的第一個提交開始，一共修復(fù)了 33942 個issues 和 49011 個 PR，十年間按 3832天計算，平均一天修復(fù) 8 個 issue，13 個 PR。
未解決問題數(shù)。目前有 7515 個 開放的問題，如果按上面的平均問題修復(fù)頻率來計算，預(yù)計 3 年左右可以修復(fù)完畢。3年以后，又是新的 Edition 發(fā)布：2024 Edtion。
存儲庫統(tǒng)計：目前 star 數(shù)有 60500 個，watch 數(shù)有 15000 個。
StackOverflow 問題數(shù)量：Rust 相關(guān)問題一共有 24924 個，平均每周 150 個問題左右，每天 20 個問題左右。相比其他語言，javascript 問題 2299100 個，Java 問題 1811376 個， Go 問題 57536 個，C 問題 368957 個，Cpp 問題 745313 個。相比于 Go ， Rust 的問題數(shù)幾乎是它的一半。
新特性發(fā)布頻率：Rust 穩(wěn)定版 每六周發(fā)一個新版。
是否穩(wěn)定：Rust 早已穩(wěn)定。
API更改頻率：穩(wěn)定版 API 基本不會更改。
是否存在“核心”開發(fā)人員：Rust 核心開發(fā)人員非常多，按工作小組來組織分配，參考 Rust 團(tuán)隊治理[6]
文檔數(shù)量和質(zhì)量：API 文檔、書籍、教程和博客。Rust API 文檔相當(dāng)成熟和先進(jìn)，目前國內(nèi)外 Rust 書籍也越來越豐富，Rust Weekly 每周都會發(fā)布社區(qū)很多 Rust 相關(guān)博客、 視頻等文章。
社區(qū)響應(yīng)頻率：有經(jīng)驗的用戶如何幫助新用戶。Rust 社區(qū)國內(nèi)外都有，通過 群組織、論壇、線下活動等幫助社區(qū)成員進(jìn)行交流。
商業(yè)支持度：Rust 基金會已經(jīng)成立：Google、華為、微軟、亞馬遜、Facebook、Mozilla 、 豐田、 動視等公司都是其董事成員。
知名項目和產(chǎn)品應(yīng)用的數(shù)量：開源 CNCF 的一些知名項目：數(shù)據(jù)庫（TiKV）、云原生（Linkerd，Krustlet）、事件流系統(tǒng)（Tremor），還有 Google Andriod 、亞馬遜、 微軟等都支持 Rust 開發(fā)，區(qū)塊鏈（Near、Solana、 Parity等）。國內(nèi)使用 Rust 的公司：螞蟻金服、PingCAP、字節(jié)跳動、秘猿、溪塔、海致星圖、非凸科技等。還有很多優(yōu)秀的項目或產(chǎn)品這里沒有列出來。
“恐怖事故”的數(shù)量，如果沒有這一項，則證明它并未在實際具有挑戰(zhàn)性的生產(chǎn)環(huán)境中使用。Rust 有專門的 信息安全工作組，并且有專門的網(wǎng)站記錄 Rust 生態(tài)中相關(guān)“恐怖事故” : https://rustsec.org/[7] 。
工具鏈支持：新的鏈接器支持（mold[8]）/ 新的 trace 工具 （tracy[9]）/ profiler 商業(yè)產(chǎn)品也支持 Rust 了（superluminal[10]）等等。
如果拿植物的成長階段（ 「播種- 發(fā)芽 - 開花 - 結(jié)果」）來類比的話，Rust 的成熟度應(yīng)該屬于 「開花」階段。
Rust 語言作為一門新生語言，雖然目前倍受歡迎，但是面臨的挑戰(zhàn)還很多。
挑戰(zhàn)主要來自兩個方面：
領(lǐng)域的選擇。一門語言唱的再好，如果不被應(yīng)用，也是沒有什么用處。Rust 語言當(dāng)前面臨的挑戰(zhàn)就是在領(lǐng)域中的應(yīng)用。而目前最受關(guān)注的是，Rust 進(jìn)入 Linux 內(nèi)核開發(fā)，如果成功，其意義是劃時代的。
語言自身特性的進(jìn)化。Rust 語言還有很多特性需要支持和進(jìn)化，這里羅列了一些待完善的相關(guān)特性。
關(guān)于領(lǐng)域的選擇，我們在下一節(jié)「Rust 在各個領(lǐng)域中的應(yīng)用狀態(tài)和趨勢」中探討。先來看看 Rust 語言自身還有哪些特性需要進(jìn)化才能順利完成 2024 Edition 的階段目標(biāo)。
Rust 語言內(nèi)存安全初步成果顯現(xiàn)
據(jù) 2021年12月31日發(fā)布于 arXiv 的論文 《SOK: On the Analysis of Web Browser Security》[11] 中所言：
比較了四種瀏覽器架構(gòu)，以及近十年來瀏覽器中內(nèi)存安全問題依然是主流。但是觀察 Firefox 通過 Oxidation 項目（Rust）替換了 12% 的組件。自2015年以來，F(xiàn)irefox 的內(nèi)存安全漏洞數(shù)量出現(xiàn)了小幅但穩(wěn)定的下降，其中，渲染器的內(nèi)存安全漏洞明顯下降。
Oxidation[12] 是專門用于將 Rust 代碼集成到 Firefox 中的一個項目。Firefox 54 以來，所有平臺都需要 Rust 支持，并且第一個主要的 Rust 組件是在 Firefox 56 (encoding_rs) 和 57 (Stylo) 中發(fā)布的。展望未來，Oxidation 的目標(biāo)是讓在 Firefox 中使用 Rust 變得更容易和更高效，并相應(yīng)地增加 Firefox 中的 Rust 代碼量。
可以說經(jīng)過六年的應(yīng)用，Rust 語言的內(nèi)存安全保障終于看到了初步的效果。該論文建議瀏覽器供應(yīng)商遵循這一最佳實踐，并逐步將他們的瀏覽器轉(zhuǎn)向內(nèi)存安全的語言。
待完善的 Rust 語言特性
Rust 語言必須解決以下問題才能順利往前發(fā)展：
錯誤處理改進(jìn) 。在 RFC 3058[13] 中描述了 Try trait 的改進(jìn)，為了達(dá)成錯誤處理大一統(tǒng)。
安全 I/O。最近Rust官方合并了一個 RFC 3128[14] ，通過引入I/O安全的概念和一套新的類型和特質(zhì)，為AsRawFd和相關(guān)特質(zhì)的用戶提供關(guān)于其原始資源句柄的保證，從而彌補(bǔ)Rust中封裝邊界的漏洞。
泛型關(guān)聯(lián)類型 GAT。泛型關(guān)聯(lián)類型在 RFC 1598 [15] 中被定義。該功能特性經(jīng)常被對比于 Haskell 中的 HKT(Higher Kinded Type)，即 高階類型。雖然類似，但是 Rust 并沒有把 Haskell 的 HKT 原樣照搬，而是針對 Rust 自身特性給出 GAT(Generic associated type) 的概念。
泛型特化（Specialization）。泛型特化這個概念，對應(yīng) Cpp 的模版特化。但是 Cpp 對特化的支持是相當(dāng)完善，而 Rust 中特化還未穩(wěn)定。在 RFC #1210[16] 中定義了 Rust 的泛型特化的實現(xiàn)標(biāo)準(zhǔn)，在 issue #31844[17] 對其實現(xiàn)狀態(tài)進(jìn)行了跟蹤。目前還有很多未解決的問題。
異步：async trait && async drop。Rust 目前異步雖然早已穩(wěn)定，但還有很多需要完善的地方。為此，官方創(chuàng)建了異步工作組，并且創(chuàng)建了 異步基礎(chǔ)計劃[18] 來推動這一過程。另外，官方也開啟了異步運(yùn)行時標(biāo)準(zhǔn)化的討論，為了達(dá)成可移植性和可互操性的異步運(yùn)行時在努力中。
協(xié)程的穩(wěn)定化。目前 Rust 的異步是基于一種半?yún)f(xié)程機(jī)制 生成器（ Generator） 來實現(xiàn)的，但生成器特性 并未穩(wěn)定。圍繞 生成器特性 穩(wěn)定的話題在 Rust 論壇不定期會提出，因為 生成器特性 在其他語言中也是比較常見且有用的特性。
可移植的 SIMD。Rust 官方團(tuán)隊發(fā)布了 `portable-simd`[19] ，你可以在 Nightly 下使用這個庫來代替 packed_simd[20] 了。這個庫使得用 Rust 開發(fā)跨平臺 SIMD 更加容易和安全。在不久的將來，也會引入到標(biāo)準(zhǔn)庫中穩(wěn)定下來。
新的 asm! 支持。asm! 宏允許在 Rust 中內(nèi)聯(lián)匯編。在 RFC #2873[21] 中規(guī)定了新的 asm!宏語法，將用于兼容 ARM、x86 和 RISC-V 架構(gòu) 等，方便在未來添加更多架構(gòu)支持。之前的 asm! 宏被重命名為 llvm_asm!。目前新的 asm! 已經(jīng)接近穩(wěn)定狀態(tài)，可在 issue #72016[22] 中跟蹤?？偟膩碚f，就是讓 asm! 宏更加通用，相比于 llvm_asm!，它有更好的語法。
Rustdoc 提升。Rust 是一門優(yōu)雅的語言。并且這份優(yōu)雅是非常完整的。除了語言的諸多特性設(shè)計優(yōu)雅之外，還有一個亮點就是 Rustdoc。Rust 官方 doc 工作組勵志讓 Rustdoc 成為一個偉大的工具。Rustdoc 使用簡單，可以創(chuàng)建非常漂亮的頁面，并使 編寫文檔成為一種樂趣。關(guān)于 Rustdoc 詳細(xì)介紹你可以去看 Rustdoc book[23] 。
持續(xù)穩(wěn)定 Rust for Linux 未穩(wěn)定特性心愿單[24] 中所列清單。這個是和 Rust for Linux 團(tuán)隊一起完成的。
新的 GCC 后端。為了推動 Rust for Linux ，Rust 支持新的 GCC后端也是早已提上日程的事了。其中 rustc_codegen_gcc進(jìn)展最快，目前已通過了部分的 rustc 測試，rustc_codegen_llvm是目前的主要開發(fā)項目，Rust GCC預(yù)計在 1~2 年內(nèi)完成。
穩(wěn)定 分配器 API 。添加標(biāo)準(zhǔn)分配器接口并支持用戶定義的分配器，允許不同的集合支持不同的分配器，等等。具體在 RFC 1398[25] 中有完整描述。目前狀態(tài)是為 Vec<T> 增加了一個分配器泛型參數(shù)。
上面羅列的只是 Rust 待完善問題的一部分工作而已，還有很多內(nèi)容沒有列出來。Rust 語言還在不斷進(jìn)化中。
Rust 開源治理中凸顯的問題
今年 Rust 開源組織發(fā)生了Rust 語言審核團(tuán)隊（mod team）集體離職的事件，引起國內(nèi)外技術(shù)社區(qū)廣泛討論。
據(jù)官方描述[26]矛盾產(chǎn)生于審核團(tuán)隊和核心團(tuán)隊成員之間關(guān)于如何處理審核問題時造成的分歧。因為這些矛盾涉及了很多相關(guān)人員很多個人隱私，所以官方也不能透露更多內(nèi)幕信息，這就導(dǎo)致外界對這件事有很多猜測和夸大影響。這件事本來也就是 Rust 官方團(tuán)隊內(nèi)部事件，其實根本沒有必要讓外界知道。
要管理一個規(guī)模超過大多數(shù)公司，卻由志愿者組成的開源項目是很困難的。他們有很多工作要做，但他們相信Rust Project會因此變得更加強(qiáng)大。雖然這些問題很嚴(yán)重，需要謹(jǐn)慎地得出積極的結(jié)論，但他們相信這不會對Rust語言及其核心工具、文檔和支持進(jìn)行改進(jìn)的能力產(chǎn)生負(fù)面影響。
對于關(guān)心 Rust 的 中文社區(qū)的朋友和技術(shù)媒體而言，我覺得沒必要過度解讀。因為我們不了解美國社會以及處于該社會下人們所關(guān)心和敏感的問題是什么，真正想去理解也是比較困難的，因為有文化差異。我們只知道，這是一個超過大多數(shù)公司人員規(guī)模且都是志愿者組成的開源組織所要面臨和解決的問題，問題一旦經(jīng)過解決，那么這個社區(qū)將得到進(jìn)化，會更加強(qiáng)大。所以沒必要擔(dān)心什么 Rust 會被負(fù)面影響。
但此時，我又想起 2020 年 Rust 1.44 版本發(fā)布時，官方博客說過這么一句話：「tech is and always will be political」。
當(dāng)時，正好趕上了明洲白人警察跪殺黑人事件，美國的所有企業(yè)現(xiàn)在都在站隊。所以，Rust 官方也必須得表個態(tài)：堅決反對美國警察的暴行。當(dāng)時看上去好像很正常，但我沒有注意到在官方內(nèi)網(wǎng)上對此已經(jīng)有了 很多討論[27] ，現(xiàn)在回頭再看這件事，感覺審核團(tuán)隊離職事件并非偶然。
對于美國文化不太了解的我，之前還對審核團(tuán)隊存在的重要性嗤之以鼻，現(xiàn)在感覺審核團(tuán)隊的存在對于 Rust 這樣深處文化政治復(fù)雜的美國是多么重要。我終于理解 Rust 官方團(tuán)隊所說這件事的背景相當(dāng)復(fù)雜的原因了。
真心希望 Rust 社區(qū)少一些政治、種族等非技術(shù)言論和矛盾。Rust 語言是全球的，不是某個國家的。真心希望 Rust 團(tuán)隊能處理好這件事。對此，我們能做些什么呢？也許只能祈禱世界和平。
Rust 在各個領(lǐng)域中的應(yīng)用狀態(tài)和趨勢
操作系統(tǒng)
先從操作系統(tǒng)來看起。
Rust for Linux
從 2020 年 6 月，Rust 進(jìn)入Linux 就開始成為一個話題。Linux 創(chuàng)建者 Linus 在當(dāng)時的開源峰會和 嵌入式Linux 會議上談到了為開源內(nèi)核尋找未來維護(hù)者的問題。
Linus 提到：“內(nèi)核很無聊，至少大多數(shù)人認(rèn)為它很無聊。許多新技術(shù)對很多人來說應(yīng)該更加有趣。事實證明，很難找到維護(hù)者。雖然有很多人編寫代碼，但是很難找到站在上游對別人代碼進(jìn)行 Review 的人選。這不僅僅是來自其他維護(hù)者的信任，也來自所有編寫代碼的人的信任……這只是需要時間的”。
Rust 作為一門天生安全的語言，作為C的備選語言，在幫助內(nèi)核開發(fā)者之間建立彼此的信任，是非常有幫助的。三分之二的 Linux 內(nèi)核安全漏洞( PDF[28] )來自內(nèi)存安全問題，在 Linux 中引入 Rust 會讓其更加安全，這目前基本已經(jīng)達(dá)成一種共識。
在今年（2021）的 開源峰會上， Linus 說道：“我認(rèn)為C語言是一種偉大的語言，對我來說，C 語言確實是一種在相當(dāng)?shù)偷乃缴峡刂朴布姆椒?。因此，?dāng)我看到C語言代碼時，我可以非常接近地猜測編譯器的工作。它是如此接近硬件，以至于你可以用它來做任何事情。但是，C語言微妙的類型交互并不總是合乎邏輯的，對幾乎所有人來說都是陷阱。它們很容易被忽視，而在內(nèi)核中，這并不總是一件好事。Rust 語言是我看到的第一種看起來像是真的可以解決問題的語言。人們現(xiàn)在已經(jīng)談?wù)揜ust在內(nèi)核中的應(yīng)用很久了，但它還沒有完成，可能在明年，我們會開始看到一些首次用Rust編寫的無畏的模塊，也許會被整合到主線內(nèi)核中?！?/span>
Linus 認(rèn)為 Linux 之所以如此長青，其中一個重要的基石就是 樂趣（Fun），并且 樂趣也是他一直追求的東西。當(dāng)人們討論 使用Rust編寫一些Linux內(nèi)核模塊的可能性時，樂趣就出現(xiàn)了。
在剛過去的 2021 年 9 月 的 Linux Plumbers 大會上， 再一次討論了 Rust 進(jìn)入 Linux 內(nèi)核的進(jìn)展。
Rust for Linux 的主力開發(fā)者 Miguel Ojedal 說，Rust 如果進(jìn)入內(nèi)核，就應(yīng)該是一等公民的角色。Linus 則回答，內(nèi)核社區(qū)幾乎肯定會用該語言進(jìn)行試驗。
Rust 進(jìn)入內(nèi)核肯定會有一些維護(hù)者需要學(xué)習(xí)該語言，用來 review Rust 代碼。Linus 說， Rust 并不難懂，內(nèi)核社區(qū)任何有能力 review patch 的人都應(yīng)該掌握 Rust 語言到足以 Review 該語言代碼的程度。
Ojedal 說，目前內(nèi)核工作還再使用一些 Unstable 的 Rust 特性，導(dǎo)致兼容性不夠好，不能確保以后更新的 Rust 編譯器能正常編譯相關(guān)代碼。但是 如果 Rust 進(jìn)入 Linux 內(nèi)核，就會改變這種情況，對于 一些 Unstable Rust 特性，Rust 官方團(tuán)隊也會考慮讓其穩(wěn)定。這是一種推動力，遲早會建立一個只使用 Rust 穩(wěn)定版的 內(nèi)核，到時候兼容問題就會消失。
另一位內(nèi)核開發(fā)者 Thomas Gleixner 擔(dān)心 Rust 中并沒有正式支持內(nèi)存順序，這可能會有問題。但是另一位從事三十年cpp 并發(fā)編程的 Linux 內(nèi)核維護(hù)者 Paul McKenney 則寫了一系列文章[29]來探討 Rust 社區(qū)該如何就Rust 進(jìn)入 Linux 內(nèi)核這件事正確處理 內(nèi)存順序模型。對此我也寫了另一篇文章 【我讀】Rust 語言應(yīng)該使用什么內(nèi)存模型？ 。
關(guān)于 Rust 對 GCC 的支持，其中 rustc_codegen_gcc進(jìn)展最快，目前已通過了部分的 rustc 測試，rustc_codegen_llvm是目前的主要開發(fā)項目，Rust GCC預(yù)計在 1~2 年內(nèi)完成。
這次大會的結(jié)論是：
Rust 肯定會在 Linux 內(nèi)核中進(jìn)行一次具有時代意義的實驗。
Rust 進(jìn)入 Linux 內(nèi)核，對于 推動 Rust 進(jìn)化具有很重要的戰(zhàn)略意義。
2021 年 11 月 11 日，在 Linux 基金會網(wǎng)站上，又放出另一場錄制的網(wǎng)絡(luò)會議：Rust for Linux：編寫安全抽象和驅(qū)動程序[30]，該視頻中 Miguel Ojeda 介紹了 Rust 如何在內(nèi)核中工作，包括整體基礎(chǔ)設(shè)施、編譯模型、文檔、測試和編碼指南等。
我對這部分視頻內(nèi)容做了一個簡要總結(jié)：
介紹 Unsafe Rust 和 Safe Rust。
在 Linux 內(nèi)核中使用 Rust ，采用一個理念：封裝 Unsafe 操作，提供一個 安全抽象給 內(nèi)核開發(fā)者使用。這個安全抽象位于 https://github.com/Rust-for-Linux/linux/tree/rust/rust[31] 的 kernel 模塊中。
給出一個簡單的示例來說明如何編寫 內(nèi)核驅(qū)動
對比 C 語言示例，給出 Rust 中什么是 Safety 的行為。
介紹了 文檔、測試和遵循的編碼準(zhǔn)則。
2021.12.6 早上發(fā)出了更新的補(bǔ)丁，介紹了在內(nèi)核中處理 Rust 的初始支持和基礎(chǔ)設(shè)施。
這次更新的內(nèi)容包括：
升級到了最新 Stable 編譯器和 Rust 2021 edition 。因此可以擺脫了 const_fn_transmute，const_panic、const_unreachable_unchecked、core_panic 和try_reserve 這幾個之前未穩(wěn)定的特性。未穩(wěn)定特性心愿單[32]。
自定義 core 和 alloc。為 alloc 添加了更加模塊化的選項，以便禁用一些他們不需要的功能：no_rc 和 no_sync，主要是為上游 Rust 項目添加。
更嚴(yán)格的代碼、文檔和新的 lint。
抽象和驅(qū)動程序更新。添加了序列鎖、電源管理回調(diào)的抽象，io 內(nèi)存（readX/writeX）、irq 芯片和高級流處理程序，gpio 芯片（包括 irq 芯片）、設(shè)備、amba 設(shè)備和驅(qū)動程序以及證書。此外，也改進(jìn)并簡化了 Ref（refcount_t 支持）對象并用它替換了 Rust 的 Arc 的所有實例。完全地從 alloc crate 中刪除了 Arc 和 Rc。
從現(xiàn)在開始，Rust for linux 團(tuán)隊將開始定期提交補(bǔ)丁，每兩周左右。
除了來自 Arm、Google 和 Microsoft 的支持外，這次該團(tuán)隊又收到一封來自紅帽的信：紅帽對 Rust 用于內(nèi)核的工作也非常感興趣（There is interest in using Rust for kernel work that Red Hat is considering）。
v2 補(bǔ)?。篽ttps://lore.kernel.org/lkml/[email protected]/[33]
https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-v2[34]
kernel crate 文檔[35]
綜合上面我們了解到的這些信息，2022 年，我們很可能會看到 Linux 內(nèi)核中的實驗性 Rust 編程語言支持成為主流。如果這次實驗成功，那么就意味著 Rust 正式從 C 語言手里拿到了時代的交接棒。
Redox + Theseus
Redox 是 純 Rust 實現(xiàn)的類似于 MINIX[36] 的微內(nèi)核設(shè)計，它提供了內(nèi)存分配器、文件系統(tǒng)、顯示管理器、核心實用程序等等，它們共同構(gòu)成了一個功能性操作系統(tǒng)。
Redox 的發(fā)起者雖然在 System76 工作，但實際上 Redox 這個項目并未得到 System76 的贊助。我曾經(jīng)以為 Redox 屬于 System76 的商業(yè)開源項目，但最近才發(fā)現(xiàn)，Redox 的花費(fèi)都是來自于社區(qū)贊助。Redox 的主要開支基本都是用于 Redox OS Summer of Code ，招募一些學(xué)生，為其完善功能。
Redox 在 2021 年比較重要的一個動態(tài)是，另一個 Rust 實現(xiàn)的操作系統(tǒng) Theseus[37] 宣布加入 Redox 。
現(xiàn)代 OS 中不同進(jìn)程會共享很多狀態(tài)，這會導(dǎo)致 state spill 的問題，比如，如果 Android 系統(tǒng)服務(wù)失敗，“整個用戶空間框架”就會崩潰，影響所有應(yīng)用程序，甚至影響那些不使用失敗服務(wù)的應(yīng)用程序。
Theseus OS 有許多微小的組件，稱為單元，每個都有明確的界限。每個單元都是一個 Rust crate。然而，更大的創(chuàng)新是他們所謂的“語內(nèi)（Intralingual）操作系統(tǒng)設(shè)計”，他們的意思是使用編程語言機(jī)制來實現(xiàn)操作系統(tǒng)，即，“將語義錯誤從運(yùn)行時錯誤轉(zhuǎn)變?yōu)榫幾g時錯誤”。這意味著，Theseus 相比于其他 OS 與 Rust 的關(guān)系更加緊密。
Theseus OS 故障恢復(fù)涉及用新的單元替換損壞的單元。研究人員聲稱，這“允許 Theseus 在面對多個故障子系統(tǒng)時容忍最低系統(tǒng)層中的故障。” 這是一種單元交換技術(shù)，也許這就是 Theseus 這個名字的由來，忒修斯之船的故事應(yīng)該都聽過吧？
嵌入式 OS
Tock OS 2.0
Tock[38] 是一個嵌入式操作系統(tǒng)，設(shè)計用于在基于Cortex-M和RISC-V的嵌入式平臺上運(yùn)行多個并發(fā)的、互不信任的應(yīng)用程序。Tock的設(shè)計以保護(hù)為中心，既可以防止?jié)撛诘膼阂鈶?yīng)用程序，也可以防止設(shè)備驅(qū)動程序。Tock使用兩種機(jī)制來保護(hù)操作系統(tǒng)的不同組件。首先，內(nèi)核和設(shè)備驅(qū)動程序是用Rust編寫的，Rust是一種提供compile-time內(nèi)存安全、類型安全和嚴(yán)格別名的系統(tǒng)編程語言。Tock使用Rust來保護(hù)內(nèi)核（例如調(diào)度程序和硬件抽象層）不受特定于平臺的設(shè)備驅(qū)動程序的影響，并將設(shè)備驅(qū)動程序彼此隔離。其次，Tock使用內(nèi)存保護(hù)單元將應(yīng)用程序彼此和內(nèi)核隔離開來。
Google發(fā)布的這個 OpenSK 是跑在 Tock上面的！OpenSK [39]是用Rust編寫的安全密鑰的開源實現(xiàn)，該密鑰同時支持FIDO U2F和FIDO2標(biāo)準(zhǔn)。
今年 Tock OS 的一個動作是，它升級到了 2.0 版本，并且這次升級是一次重大更新，完全是新內(nèi)核，核心內(nèi)核 API 被重新設(shè)計。
并且對芯片和開發(fā)板的支持基本覆蓋的非常全面：RISC-V / ARM CortexM0+ / ARM CortexM7 / Nano RP2040 / Rapsberry Pi Pico/ ESP32-C3-DevKitM-1 等等。
Hubris
Hubris[40] 沒有運(yùn)行時創(chuàng)建或銷毀任務(wù)的操作，沒有動態(tài)資源分配，沒有以特權(quán)模式運(yùn)行的驅(qū)動程序代碼，系統(tǒng)中也沒有C代碼。通過這種構(gòu)造，消除了許多通常存在于類似系統(tǒng)中的攻擊面。
OXide 公司在今年 OSFF Mini Summit 2021 會議上分享了 即將到來的固件革命[41] 中提到，Rust 將會是即將到來的固件革命的一部分。所以，他們重新審視嵌入式操作系統(tǒng)并用 Rust 開發(fā)了 Hubris。Hubris 目前只支持 Arm Cortex M 平臺。
Hubris vs TockOS ：
Tock 使用動態(tài)加載，Hubris是靜態(tài)的
Tock 是非常異步的，Hubris是嚴(yán)格同步的
Tock 的驅(qū)動程序與內(nèi)核在同一保護(hù)區(qū)，Hubris 的驅(qū)動程序位于不同的投影域中
其他
新版VxWorks
風(fēng)河 VxWorks[42] 是一款確定性、基于優(yōu)先級的搶占式實時操作系統(tǒng)，具有超低延遲和最小抖動。其官網(wǎng)在最新版宣布 唯一支持 C ++ 17、Boost、Rust、Python、pandas等開發(fā)語言的實時操作系統(tǒng)。
云原生
Linkerd2
2021 年對于 Linkerd 來說是標(biāo)志性的一年。該項目在 Cloud Native Computing Foundation 中畢業(yè)了[43]，它代表項目成熟度的最高級別。Linkerd 的采用率在今年飆升，組織范圍廣泛，如Microsoft[44]、S&P Global[45]，以及挪威勞工和福利管理局[46]，以及許多其他機(jī)構(gòu)，都公開采用了 Linkerd。
Linkerd 2.11 在 2021 年 9 月發(fā)布[47]，更多組件向 Rust 遷移。Linkerd 之前只有 proxy 部分是 Rust 實現(xiàn)，發(fā)布的 2.11.0 版本中，Linkerd 采用了一個用 Rust 編寫的新策略控制器組件！它使用 kube-rs 與 Kubernetes API 進(jìn)行通信，并暴露了一個用 Tonic 實現(xiàn)的 gRPC API。
雖然 Linkerd 在數(shù)據(jù)面有豐富的Rust經(jīng)驗，但他們選擇Go作為控制面組件，因為Kubernetes生態(tài)系統(tǒng)（以及它的API客戶端等）是如此嚴(yán)重地傾向于Go。然而，由于u/clux在kube-rs上的出色工作，現(xiàn)在用Rust實現(xiàn)控制器已經(jīng)變得可行。這對Linkerd項目來說是一大進(jìn)步，他們計劃在整個項目中更多地使用Rust。它發(fā)布了多個基準(zhǔn)測試，顯示性能和資源使用領(lǐng)先于 Istio 一個數(shù)量級[48]；它繼續(xù)引領(lǐng)著將 Rust 帶入[49]云原生領(lǐng)域。他們希望Linkerd的這個新方向?qū)⒂兄跉g迎更多希望增長Rust實踐經(jīng)驗的貢獻(xiàn)者。
如果對 Linkerd2 的 2022 年路線圖感興趣可以點擊這里[50]。
Deislabs[51] 的項目
Akri
Akri [52] 是 云原生計算基金會 (CNCF)的一個沙盒項目，用于為 Kubernetes 提供邊緣計算解決方案。Akri 旨在成為在邊緣的 Kubernetes 集群上使用物聯(lián)網(wǎng)設(shè)備的標(biāo)準(zhǔn)方式，這就是為什么 Akri 在希臘語中不僅意味著“邊緣”，而且還代表 Kubernetes 資源接口。
Krustlet
Krustlet[53] 是一種 kubelet[54] 實現(xiàn)，使用戶能夠在同一個 Kubernetes 集群中運(yùn)行 WebAssembly 和傳統(tǒng)容器工作負(fù)載。
在 2021 年，Krustlet 和 krator[55] 項目（Kubernetes Rust 狀態(tài)機(jī)操作框架）一起成為了 CNCF 的沙盒項目，到目前為止，已經(jīng)發(fā)布了 1.0-alpha.1 版本，1.0 正式版本即將發(fā)布。
那么，這個 1.0究竟意味著什么？它意味著穩(wěn)定性和向后兼容性保證。人們就可以開始用它構(gòu)建一些真正的產(chǎn)品了。隨著 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的每日請求流量經(jīng)歷了爆炸性的增長，比1月份的每日流量暴漲了31,000%以上?？蛻羰褂昧坑型?021年達(dá)到2萬億次總請求，目標(biāo)是在2022年底達(dá)到50萬億次。
而這個 Compute@Edge[58] 是 Fastly 的邊緣計算平臺，它能夠運(yùn)行你在自己的系統(tǒng)上編譯并上傳到 Fastly 的自定義二進(jìn)制文件。通過將代碼編譯到WebAssembly[59]來提供安全性和可移植性，他們使用 Lucet[60] 在邊緣運(yùn)行它，Lucet 是由 Fastly 創(chuàng)建的開源 WebAssembly 運(yùn)行時。而 Lucet 是基于字節(jié)碼聯(lián)盟的 wasmtime[61] WebAssembly 運(yùn)行時來實現(xiàn)的。
其他
在 WebAssembly Serverside 領(lǐng)域，還有很多極具創(chuàng)新的產(chǎn)品：
WasmEdge，是用于邊緣計算和軟件定義車輛的輕量級、快速和任務(wù)關(guān)鍵型代碼 runtime 。目標(biāo)是大幅降低復(fù)雜性并提高開發(fā)速度。它是目前市場上最快的 Wasm 虛擬機(jī)，由 Cpp 開發(fā)，但是現(xiàn)在正在開發(fā) Rust SDK，會全面擁抱 Rust。
WasmCloud[62]，是一個基于 WebAssembly 的分布式計算平臺，目前也是 CNCF 沙盒項目。比較有創(chuàng)新的地方在于，它制定了一個 waPC 標(biāo)準(zhǔn)，用于 Guest 和 Host 的安全過程調(diào)用，來解決當(dāng)前 WASI 等特性不完善的問題。
字節(jié)跳動的飛書、安全部門、基礎(chǔ)設(shè)施部門都已經(jīng)用上了 Rust ，并且還開源了一些基礎(chǔ)庫[63]。
其中比較出色的可用于云原生項目的有：
monoio[64]，是一個基于 io-uring 的 Thread-per-core 模型的異步 Runtime，詳細(xì)介紹參見:《Rust 異步運(yùn)行時的設(shè)計與實現(xiàn)》[65]
keyhouse[66] ，字節(jié)內(nèi)部使用的密鑰管理系統(tǒng)已經(jīng)在github上開源了，支持加解密和敏感配置管理。目前字節(jié)內(nèi)部很多業(yè)務(wù)都基于該系統(tǒng)進(jìn)行開發(fā)。
物聯(lián)網(wǎng)（IoT）
Rust 嵌入式工作組進(jìn)展
樹莓派2021發(fā)布首款RP2040微控制器中有兩個Cortex M0內(nèi)核。這讓工作組的成員開始思考，在多核微控制器下該如何提供安全性，由此有了 rp-rs 組織。
Espressif （樂鑫）正式雇傭mabez 針對eso芯片開發(fā)Rust支持：esp-rs
其他平臺也逐漸開始支持Rust，包括：Atmel ARM SAM-D和SAM-E、Atmel AVR、NXP ARM iMX. RT微控制器、ARM nRF51、52和9160藍(lán)牙/LTE設(shè)備、RISC-V、樹莓派、STM32等。
嵌入式Rust生態(tài)得到長足發(fā)展：
嵌入式并發(fā)框架RTIC[67]已經(jīng)1.0
嵌入式異步框架Embassy[68]正在大力開發(fā)且支持STM32，nRF和RP2040平臺，并且還深深影響著Rust異步的改進(jìn)
嵌入式開發(fā)和調(diào)試工具Knurling[69]又發(fā)布了新的探針工具
嵌入式 TCP/IP棧smoltcp[70] 發(fā)布了新版本
嵌入式圖形庫embedded-graphics[71] 發(fā)布了新版本
新的嵌入式實時OS Hubirs 開源。
嵌入式工作組自身維護(hù)的項目在這一年也是大力開發(fā)和維護(hù)中。
更多參見: https://blog.rust-embedded.org/this-year-in-embedded-rust-2021/[72] 。
總的來說，Rust 在嵌入式領(lǐng)域越來越成熟了。
樂鑫芯片(Espressif) esp-rs 進(jìn)展
2021 年，樂鑫公司宣布雇傭 mabez 來全職從事 Rust 對 ESP32 的支持，對應(yīng)GitHub 開源組織是 esp-rs[73]。這意味著，Rust 將全面進(jìn)入 esp32 領(lǐng)域。
截止年底，mabez 完成的工作可以在其博客看到，總的來說目前進(jìn)度為：
esp-rs book[74]
probe-rs 對 esp32c3 的支持現(xiàn)在比較完善了
espflash 達(dá)到了 1.0
引入 esp32-hal[75]
其他，還有很多
更多更新可以參見 Rust on Espressif chips - 10-01-2022[76] 。不得不說，樂鑫是一家很有遠(yuǎn)見的公司。
趨勢
ARM 是迄今為止在物聯(lián)網(wǎng)邊緣使用的芯片組和傳感器等嵌入式設(shè)備的領(lǐng)先制造商，今年已經(jīng)加入了 Rust 基金會。
Rust 完全有能力在嵌入式計算等更高級別的物聯(lián)網(wǎng)領(lǐng)域完成特定任務(wù)，例如邊緣輕量級計算和后端服務(wù)的實現(xiàn)，并同時可以在一定程度上滿足這類物聯(lián)網(wǎng)基礎(chǔ)設(shè)施的功能安全需求。
由于其生態(tài)系統(tǒng)與物聯(lián)網(wǎng)相關(guān)的部分，仍在不斷發(fā)展，甚至缺乏一些重要的基礎(chǔ)，而且遠(yuǎn)非穩(wěn)定。但從好的方面來說，我們看到像 Drogue、Ferrous Systems 和其他獨(dú)立的幾家公司正在努力推動 Rust 進(jìn)入物聯(lián)網(wǎng)領(lǐng)域而對至關(guān)重要的基礎(chǔ)正在進(jìn)行積極的開發(fā)，并為 Rust 帶來更光明的未來。
游戲
GPU 圖形渲染值得關(guān)注的項目
rust-gpu
rust-gpu[77] 是 embark studios 開源的一個項目，致力于讓 Rust 成為圖形渲染領(lǐng)域的第一類語言。目前正聯(lián)合 Traverse research 公司一起構(gòu)建rust-gpu。
Embark 是和韓國游戲公司 Nexon （《冒險島》《跑跑卡丁車》）合開的。Embark CEO 是前EA 首席設(shè)計官 Patrick ，曾是《戰(zhàn)地》系列開發(fā)商 DICE 的 CEO。Embark 也是 Rust 游戲工作組的成員之一，該公司也贊助了很多 Rust 生態(tài)開源項目的作者。
Traverse research 公司位于荷蘭 Breda 中心區(qū)，愿景是讓Breda 成為游戲開發(fā)強(qiáng)鎮(zhèn)。該團(tuán)隊的核心成員在圖形學(xué)領(lǐng)域造詣很強(qiáng)。
rust-gpu 主要是針對圖形渲染引擎，希望可以把 Rust 引入為一種著色語言。通過 rustc 后端 編譯到 spir-v （著色器的二進(jìn)制中間語言 ）來達(dá)成這個目標(biāo)。目前該領(lǐng)域常用的是 GLSL/HLASL ，但它們并未隨著游戲行業(yè)發(fā)展提供處理大型代碼庫的機(jī)制，所以在這個領(lǐng)域急需一門優(yōu)秀的著色語言，而 embark 的人們認(rèn)為 Rust 就是最佳選擇，所以他們做了這項工作。
embark 還基于 rust-gpu 開源了一個實驗性的全局光照渲染引擎 kajiya[78]。
Rust-CUDA
Rust-CUDA[79] 則是一個旨在使 Rust 成為使用 CUDA 工具包進(jìn)行極快 GPU 計算的 1 級（tier-1）語言的項目。該團(tuán)隊希望通過這個項目，可以推動 Rust GPU 計算行業(yè)向前發(fā)展，并使 Rust 成為此類任務(wù)的優(yōu)秀語言。Rust 提供了很多好處，例如高效利用每個內(nèi)核的性能優(yōu)勢、出色的模塊/crate系統(tǒng)、用 unsafe分隔 CPU/GPU 代碼的不安全區(qū)域、為底層 CUDA 庫構(gòu)建高級包裝器等。
游戲引擎中的佼佼者
Bevy
Bevy[80] 是一個基于 Rust 實現(xiàn)的 數(shù)據(jù)驅(qū)動游戲引擎。相比于 Rust 實現(xiàn)的其他游戲引擎，比如 Amethyst， Bevy 屬于后來著居上。Bevy 在 API 設(shè)計方面獨(dú)具匠心，充分利用 Rust 語言特點，讓開發(fā)者上手非常簡單方便。得力于其 Plugin 機(jī)制，目前 Bevy 已經(jīng)逐漸形成自己的生態(tài)，逐步涌現(xiàn)出很多基于 Bevy 的 Plugin 。
Bevy 作為開源項目，在 GitHub 上接受的贊助現(xiàn)在基本已經(jīng)達(dá)成了每月 6000 美刀的目標(biāo)。雖然目前 Bevy 只發(fā)布了 0.6 版本，但是其生態(tài)在逐步建立，并且受到很多人的歡迎和期許。
Bevy 0.6 版本中有大量改進(jìn)、錯誤修復(fù)和質(zhì)量提升，這里羅列一部分：
一個全新的現(xiàn)代渲染器，更漂亮、更快、更易于擴(kuò)展
原生 WebGL2 支持。您可以通過在瀏覽器中運(yùn)行 Bevy 示例[81]來測試它！[82]
更強(qiáng)大的著色器：預(yù)處理器、導(dǎo)入、WGSL 支持
Bevy ECS 人體工程學(xué)和性能改進(jìn)。沒有了.system()！
更多參見Bevy 0.6 介紹[83] 。
Fyrox(Rg3d)
Fyrox(rg3d)[84] 是另一款 Rust 實現(xiàn)的游戲引擎，支持 3D 和 2D ，之前項目名為 rg3d，現(xiàn)在已經(jīng)改名為 Fyrox[85] 。
該游戲引擎雖然沒有 bevy 那樣受人關(guān)注，但也在高速發(fā)展中，目前已經(jīng)發(fā)布了 0.24 版本。簡單來說的變化：
2d 支持。從一開始，引擎只專注于 3D 游戲，但在 rg3d 0.23 中情況發(fā)生了一些變化，添加了一個簡單的 2D 場景版本。
增加了開發(fā)指南
物理集成
引入了聲音引擎 rg3d-sound
詳細(xì)參見 rg3d 0.24 功能亮點[86]
Amethyst 新的開始
Amethyst 引擎宣布停止開發(fā)[87]，游戲引擎的火炬?zhèn)鬟f給了 Bevy，未來 Amethyst 基金會還會在游戲領(lǐng)域創(chuàng)造價值，但不局限于游戲引擎。
為什么會這樣？
Amethyst 從自上而下的BDFL模式轉(zhuǎn)為扁平的對等模式之后，一直沒有找到自己的立足點。團(tuán)隊內(nèi)部對 Amethyst 的目標(biāo)缺乏統(tǒng)一看法。
Bevy 引擎發(fā)展的不錯，將會把 Amethyst 引擎的火炬?zhèn)鬟f下去。
BDFL: BDFL 是英文「Benevolent Dictator For Life」的縮寫。中文翻譯為「仁慈的終身獨(dú)裁者」。在此架構(gòu)下，有一個人（通常是項目的最初的作者，或者是社區(qū)選舉的一個人）擁有項目中所有最后的決定。較小的項目可能默認(rèn)就是 BDFL 結(jié)構(gòu)，因為此類項目一般就是一到兩位維護(hù)者。若是公司組織的項目也極有可能會采用 BDFL 結(jié)構(gòu)，以便掌握項目的決策權(quán)。
數(shù)據(jù)處理
Databend 數(shù)據(jù)云
數(shù)據(jù)流處理
Tremor
深挖了一下 tremor-runtime 項目背后的公司，原來是 Wayfair 。Wayfair 是美國最大的家具電商，2017 年市值就達(dá)58億美元，前身是早在2002年就成立的CNSStores。亞馬遜都吃不下它。
Tremor 應(yīng)該是 Wayfair 公司旗下的開源項目，已經(jīng)進(jìn)入 CNCF 。2021 年 九月份還召開了一次小型的線上的 Tremor Conf[90] 2020年3月份的一次分享：Rust 如何為 Wayfair 省掉數(shù)千個核心和TB級的內(nèi)存的成本 ：2020-03-31-RustAndTellBerlin-functions[91]
從2018年開始， tremor 就是跑在了 wayfair生產(chǎn)環(huán)境中，每天處理10兆字節(jié)的數(shù)據(jù)，或每分鐘100億條消息，每秒1000萬個指標(biāo)。tremor 降低了成本，減少了復(fù)雜性，鞏固和簡化了操作環(huán)境，以激發(fā)SRE的樂趣，減少NOC的工作量，并降低運(yùn)營成本。
實時分析的流式數(shù)據(jù)庫 Materialize
其他
fluvio[95] : 是一個開源數(shù)據(jù)流平臺，可聚合、關(guān)聯(lián)并將可編程智能應(yīng)用于動態(tài)數(shù)據(jù)。Fluvio 由 Rust 提供支持，在云原生架構(gòu)上提供低延遲、高性能的可編程流。
vector[96]: 用于構(gòu)建可觀察性管道的輕量級、超快速工具。
圖數(shù)據(jù)庫
海致星圖：金融級分布式高性能圖數(shù)據(jù)庫
感謝閱讀
參考資料