2021 年 Rust 生态调研报告 | 星辰大海（上篇）

2022 年 1 月 12 日 InfoQ

作者｜张汉东

文前

半年前，我写了一篇《三万言｜2021 年 Rust 行业调研报告》（https://zhuanlan.zhihu.com/p/383034421），内容主要围绕 Rust 语言介绍和行业领域开源应用盘点两大部分内容。时隔半年，我觉得有必要再写一篇年终的 Rust 生态调研报告。因为我想给大家提供一个比较全面的视角，通过挖掘互联网上的各种散落且隐藏的信息，最终绘制出一张 Rust 的“生态地图”，让大家尽量客观公正地去认识 Rust 语言。

在完成本篇报告之后，我得出一个观点：Rust 的出现并不是要你去用它重写一切，而是希望你可以用它创造新的未来。当然这只是我个人观点，不代表任何人任何机构和公司。如果您有不同观点，欢迎探讨。

本次报告的所有内容都来自于互联网公开信息，如有错误或不宜在本报告中提及的内容，请及时告知。

大纲

本次报告包含以下内容：

Rust Project 自身状态
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/nikomatsakis/salsa）。另外还处理了一些向后兼容的问题，以及持续投入一些影响未来发展的关键特性，比如常量泛型、泛型关联类型等。

Rust Edition 现在已经确定了，每三年发布一个版次。这就意味着 Rust 每三年都会围绕一个引领 Rust 发展的主题。

2024 Edition 展望

2024 Edition：主题也许是「广泛应用」。

2021 年 2 月 9 号，Rust 基金会宣布成立。华为、AWS、Google、微软、Mozilla、Facebook 等科技行业领军巨头加入 Rust 基金会，成为白金成员，以致力于在全球范围内推广和发展 Rust 语言。

随后，ARM 、AUTOMATA、1PASSword、丰田汽车、动视、Knoldus 、Tangram 等各个领域中对未来充满野心的公司都加入了基金会，为推动 Rust 做贡献。

最近 Rust 基金会又推选在非营利组织有十五年经验的 Rebecca 称为了基金会的执行董事（ED）和 CEO。相信在 Rust 基金会的领导下， Rust 会有广泛的应用前景。

Rust Project 机遇与挑战

Rust 语言是完全开源的，它也是世界上最大的开源社区组织。由不同职责的团队和工作组共同协作。具体可以在 Rust 官网看到相关信息。目前拥有 3539 个贡献者。

截止目前，crates.io 上面 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 团队治理
文档数量和质量：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/ 。
工具链支持：新的链接器支持（mold）/ 新的 trace 工具（tracy）/ profiler 商业产品也支持 Rust 了（superluminal）等等。

如果拿植物的成长阶段（「播种 - 发芽 - 开花 - 结果」）来类比的话，Rust 的成熟度应该属于「开花」阶段。

Rust 语言作为一门新生语言，虽然目前倍受欢迎，但是面临的挑战还很多。

挑战主要来自两个方面：

领域的选择。一门语言唱的再好，如果不被应用，也是没有什么用处。Rust 语言当前面临的挑战就是在领域中的应用。而目前最受关注的是，Rust 进入 Linux 内核开发，如果成功，其意义是划时代的。
语言自身特性的进化。Rust 语言还有很多特性需要支持和进化，这里罗列了一些待完善的相关特性。

关于领域的选择，我们在下一节「Rust 在各个领域中的应用状态和趋势」中探讨。先来看看 Rust 语言自身还有哪些特性需要进化才能顺利完成 2024 Edition 的阶段目标。

Rust 语言内存安全初步成果显现

据 2021 年 12 月 31 日发布于 arXiv 的论文《SOK: On the Analysis of Web Browser Security》中所言：

比较了四种浏览器架构，以及近十年来浏览器中内存安全问题依然是主流。但是观察 Firefox 通过 Oxidation 项目（Rust）替换了 12% 的组件。自 2015 年以来，Firefox 的内存安全漏洞数量出现了小幅但稳定的下降，其中，渲染器的内存安全漏洞明显下降。

Oxidation 是专门用于将 Rust 代码集成到 Firefox 中的一个项目。Firefox 54 以来，所有平台都需要 Rust 支持，并且第一个主要的 Rust 组件是在 Firefox 56 (encoding_rs) 和 57 (Stylo) 中发布的。展望未来，Oxidation 的目标是让在 Firefox 中使用 Rust 变得更容易和更高效，并相应地增加 Firefox 中的 Rust 代码量。

可以说经过六年的应用，Rust 语言的内存安全保障终于看到了初步的效果。该论文建议浏览器供应商遵循这一最佳实践，并逐步将他们的浏览器转向内存安全的语言。

待完善的 Rust 语言特性

Rust 语言必须解决以下问题才能顺利往前发展：

错误处理改进。在 RFC 3058 中描述了 Try trait 的改进，为了达成错误处理大一统。
安全 I/O。最近 Rust 官方合并了一个 RFC 3128 ，通过引入 I/O 安全的概念和一套新的类型和特质，为 AsRawFd 和相关特质的用户提供关于其原始资源句柄的保证，从而弥补 Rust 中封装边界的漏洞。
泛型关联类型 GAT。泛型关联类型在 RFC 1598 中被定义。该功能特性经常被对比于 Haskell 中的 HKT(Higher Kinded Type)，即高阶类型。虽然类似，但是 Rust 并没有把 Haskell 的 HKT 原样照搬，而是针对 Rust 自身特性给出 GAT(Generic associated type) 的概念。
泛型特化（Specialization）。泛型特化这个概念，对应 Cpp 的模版特化。但是 Cpp 对特化的支持是相当完善，而 Rust 中特化还未稳定。在 RFC #1210 中定义了 Rust 的泛型特化的实现标准，在 issue #31844 对其实现状态进行了跟踪。目前还有很多未解决的问题。
异步：async trait && async drop。Rust 目前异步虽然早已稳定，但还有很多需要完善的地方。为此，官方创建了异步工作组，并且创建了异步基础计划来推动这一过程。另外，官方也开启了异步运行时标准化的讨论，为了达成可移植性和可互操性的异步运行时在努力中。
协程的稳定化。目前 Rust 的异步是基于一种半协程机制生成器（ Generator）来实现的，但生成器特性并未稳定。围绕生成器特性稳定的话题在 Rust 论坛不定期会提出，因为生成器特性在其他语言中也是比较常见且有用的特性。
可移植的 SIMD。Rust 官方团队发布了 portable-simd ，你可以在 Nightly 下使用这个库来代替 packed_simd 了。这个库使得用 Rust 开发跨平台 SIMD 更加容易和安全。在不久的将来，也会引入到标准库中稳定下来。
新的 asm!支持。asm! 宏允许在 Rust 中内联汇编。在 RFC #2873 中规定了新的 asm! 宏语法，将用于兼容 ARM、x86 和 RISC-V 架构等，方便在未来添加更多架构支持。之前的 asm! 宏被重命名为 llvm_asm!。目前新的 asm! 已经接近稳定状态，可在 issue #72016 中跟踪。总的来说，就是让 asm! 宏更加通用，相比于 llvm_asm!，它有更好的语法。
Rustdoc 提升。Rust 是一门优雅的语言。并且这份优雅是非常完整的。除了语言的诸多特性设计优雅之外，还有一个亮点就是 Rustdoc。Rust 官方 doc 工作组励志让 Rustdoc 成为一个伟大的工具。Rustdoc 使用简单，可以创建非常漂亮的页面，并使编写文档成为一种乐趣。关于 Rustdoc 详细介绍你可以去看 Rustdoc book 。
持续稳定 Rust for Linux 未稳定特性心愿单中所列清单。这个是和 Rust for Linux 团队一起完成的。
新的 GCC 后端。为了推动 Rust for Linux ，Rust 支持新的 GCC 后端也是早已提上日程的事了。其中 rustc_codegen_gcc 进展最快，目前已通过了部分的 rustc 测试，rustc_codegen_llvm 是目前的主要开发项目，Rust GCC 预计在 1~2 年内完成。
稳定分配器 API 。添加标准分配器接口并支持用户定义的分配器，允许不同的集合支持不同的分配器，等等。具体在 RFC 1398 中有完整描述。目前状态是为 Vec<T> 增加了一个分配器泛型参数。

上面罗列的只是 Rust 待完善问题的一部分工作而已，还有很多内容没有列出来。Rust 语言还在不断进化中。

Rust 开源治理中凸显的问题

今年 Rust 开源组织发生了 Rust 语言审核团队（mod team）集体离职的事件，引起国内外技术社区广泛讨论。

据官方描述矛盾产生于审核团队和核心团队成员之间关于如何处理审核问题时造成的分歧。因为这些矛盾涉及了很多相关人员很多个人隐私，所以官方也不能透露更多内幕信息，这就导致外界对这件事有很多猜测和夸大影响。这件事本来也就是 Rust 官方团队内部事件，其实根本没有必要让外界知道。

要管理一个规模超过大多数公司，却由志愿者组成的开源项目是很困难的。他们有很多工作要做，但他们相信 Rust Project 会因此变得更加强大。虽然这些问题很严重，需要谨慎地得出积极的结论，但他们相信这不会对 Rust 语言及其核心工具、文档和支持进行改进的能力产生负面影响。

对于关心 Rust 的中文社区的朋友和技术媒体而言，我觉得没必要过度解读。因为我们不了解美国社会以及处于该社会下人们所关心和敏感的问题是什么，真正想去理解也是比较困难的，因为有文化差异。我们只知道，这是一个超过大多数公司人员规模且都是志愿者组成的开源组织所要面临和解决的问题，问题一旦经过解决，那么这个社区将得到进化，会更加强大。所以没必要担心什么 Rust 会被负面影响。

但此时，我又想起 2020 年 Rust 1.44 版本发布时，官方博客说过这么一句话：「tech is and always will be political」。

当时，正好赶上了明洲白人警察跪杀黑人事件，美国的所有企业现在都在站队。所以，Rust 官方也必须得表个态：坚决反对美国警察的暴行。当时看上去好像很正常，但我没有注意到在官方内网上对此已经有了很多讨论，现在回头再看这件事，感觉审核团队离职事件并非偶然。

对于美国文化不太了解的我，之前还对审核团队存在的重要性嗤之以鼻，现在感觉审核团队的存在对于 Rust 这样深处文化政治复杂的美国是多么重要。我终于理解 Rust 官方团队所说这件事的背景相当复杂的原因了。

真心希望 Rust 社区少一些政治、种族等非技术言论和矛盾。Rust 语言是全球的，不是某个国家的。真心希望 Rust 团队能处理好这件事。对此，我们能做些什么呢？也许只能祈祷世界和平。

Rust 在各个领域中的应用状态和趋势

接下来，我们来盘点一下 2021 年 Rust 在各个领域中应用的状态和可能的趋势是什么。

操作系统

先从操作系统来看起。

Rust for Linux

从 2020 年 6 月，Rust 进入Linux就开始成为一个话题。Linux 创建者 Linus 在当时的开源峰会和嵌入式 Linux 会议上谈到了为开源内核寻找未来维护者的问题。

Linus 提到：“内核很无聊，至少大多数人认为它很无聊。许多新技术对很多人来说应该更加有趣。事实证明，很难找到维护者。虽然有很多人编写代码，但是很难找到站在上游对别人代码进行 Review 的人选。这不仅仅是来自其他维护者的信任，也来自所有编写代码的人的信任……这只是需要时间的”。

Rust 作为一门天生安全的语言，作为 C 的备选语言，在帮助内核开发者之间建立彼此的信任，是非常有帮助的。三分之二的 Linux 内核安全漏洞 ( PDF ) 来自内存安全问题，在 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 则写了一系列文章来探讨 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：编写安全抽象和驱动程序，该视频中 Miguel Ojeda 介绍了 Rust 如何在内核中工作，包括整体基础设施、编译模型、文档、测试和编码指南等。

我对这部分视频内容做了一个简要总结：

介绍 Unsafe Rust 和 Safe Rust。
在 Linux 内核中使用 Rust ，采用一个理念：封装 Unsafe 操作，提供一个安全抽象给内核开发者使用。这个安全抽象位于 https://github.com/Rust-for-Linux/linux/tree/rust/rust 的 kernel 模块中。
给出一个简单的示例来说明如何编写内核驱动
对比 C 语言示例，给出 Rust 中什么是 Safety 的行为。
介绍了文档、测试和遵循的编码准则。

2021.12.6 早上发出了更新的补丁，介绍了在内核中处理 Rust 的初始支持和基础设施。这次更新的内容包括：

升级到了最新 Stable 编译器和 Rust 2021 edition 。因此可以摆脱了 const_fn_transmute，const_panic、const_unreachable_unchecked、core_panic 和 try_reserve 这几个之前未稳定的特性。未稳定特性心愿单。
自定义 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/20211206140313.5653-1-ojeda@kernel.org/
https://www.phoronix.com/scan.php?page=news_item&px=Rust-For-Linux-v2
kernel crate 文档（https://rust-for-linux.github.io/docs/kernel/）

综合上面我们了解到的这些信息，2022 年，我们很可能会看到 Linux 内核中的实验性 Rust 编程语言支持成为主流。如果这次实验成功，那么就意味着 Rust 正式从 C 语言手里拿到了时代的交接棒。

Redox + Theseus

Redox 是纯 Rust 实现的类似于 MINIX 的微内核设计，它提供了内存分配器、文件系统、显示管理器、核心实用程序等等，它们共同构成了一个功能性操作系统。

Redox 的发起者虽然在 System76 工作，但实际上 Redox 这个项目并未得到 System76 的赞助。我曾经以为 Redox 属于 System76 的商业开源项目，但最近才发现，Redox 的花费都是来自于社区赞助。Redox 的主要开支基本都是用于 Redox OS Summer of Code ，招募一些学生，为其完善功能。

Redox 在 2021 年比较重要的一个动态是，另一个 Rust 实现的操作系统 Theseus 宣布加入 Redox 。

现代 OS 中不同进程会共享很多状态，这会导致 state spill 的问题，比如，如果 Android 系统服务失败，“整个用户空间框架”就会崩溃，影响所有应用程序，甚至影响那些不使用失败服务的应用程序。

Theseus OS 有许多微小的组件，称为单元，每个都有明确的界限。每个单元都是一个 Rust crate。然而，更大的创新是他们所谓的“语内（Intralingual）操作系统设计”，他们的意思是使用编程语言机制来实现操作系统，即，“将语义错误从运行时错误转变为编译时错误”。这意味着，Theseus 相比于其他 OS 与 Rust 的关系更加紧密。

Theseus OS 故障恢复涉及用新的单元替换损坏的单元。研究人员声称，这“允许 Theseus 在面对多个故障子系统时容忍最低系统层中的故障。” 这是一种单元交换技术，也许这就是 Theseus 这个名字的由来，忒修斯之船的故事应该都听过吧？

嵌入式 OS

Tock OS 2.0

Tock 是一个嵌入式操作系统，设计用于在基于 Cortex-M 和 RISC-V 的嵌入式平台上运行多个并发的、互不信任的应用程序。Tock 的设计以保护为中心，既可以防止潜在的恶意应用程序，也可以防止设备驱动程序。Tock 使用两种机制来保护操作系统的不同组件。首先，内核和设备驱动程序是用 Rust 编写的，Rust 是一种提供 compile-time 内存安全、类型安全和严格别名的系统编程语言。Tock 使用 Rust 来保护内核（例如调度程序和硬件抽象层）不受特定于平台的设备驱动程序的影响，并将设备驱动程序彼此隔离。其次，Tock 使用内存保护单元将应用程序彼此和内核隔离开来。

Google 发布的这个 OpenSK 是跑在 Tock 上面的！OpenSK 是用 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 没有运行时创建或销毁任务的操作，没有动态资源分配，没有以特权模式运行的驱动程序代码，系统中也没有 C 代码。通过这种构造，消除了许多通常存在于类似系统中的攻击面。OXide 公司在今年 OSFF Mini Summit 2021 会议上分享了即将到来的固件革命中提到，Rust 将会是即将到来的固件革命的一部分。所以，他们重新审视嵌入式操作系统并用 Rust 开发了 Hubris。Hubris 目前只支持 Arm Cortex M 平台。

Hubris vs TockOS ：

Tock 使用动态加载，Hubris 是静态的
Tock 是非常异步的，Hubris 是严格同步的
Tock 的驱动程序与内核在同一保护区，Hubris 的驱动程序位于不同的投影域中

其他

新版 VxWorks

风河 VxWorks 是一款确定性、基于优先级的抢占式实时操作系统，具有超低延迟和最小抖动。其官网在最新版宣布唯一支持 C ++ 17、Boost、Rust、Python、pandas 等开发语言的实时操作系统。

Google Fuchsia

2021年5月，Google Fuchsia OS 正式发布，截止 12 月 Fuchsia 即将在第二款设备（ Nest Hub Max）上运行。

众所周知，Fuchsia 近 30% 的代码都由 Rust 实现。Fuchsia 编程语言政策对 Rust 的分析：

优点：

Fuchsia 平台源代码树在使用 Rust 方面有着积极的实施经验。
该语言提供内存安全保证，从而降低了以该语言开发的软件存在安全漏洞的风险。
可以使用直线代码编写异步程序。
Fuchsia 项目有机会影响语言的发展。

缺点：

Rust 目前还不是一种广泛使用的语言。
我们当前的终端开发人员都没有使用 Rust。

所以最终决定：

终端开发人员目前不支持 Rust。
Rust 被批准在整个 Fuchsia 平台源代码树中使用，但以下情况除外：

内核. Zircon 内核是使用一组受限制的技术构建的，这些技术已经建立了在生产操作系统中使用的行业跟踪记录。

云原生

Linkerd2

2021 年对于 Linkerd 来说是标志性的一年。该项目在 Cloud Native Computing Foundation 中毕业了，它代表项目成熟度的最高级别。Linkerd 的采用率在今年飙升，组织范围广泛，如 Microsoft、S&P Global，以及挪威劳工和福利管理局，以及许多其他机构，都公开采用了 Linkerd。

Linkerd 2.11 在 2021 年 9 月发布，更多组件向 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 一个数量级；它继续引领着将 Rust 带入云原生领域。他们希望 Linkerd 的这个新方向将有助于欢迎更多希望增长 Rust 实践经验的贡献者。

如果对 Linkerd2 的 2022 年路线图感兴趣可以点击这里（https://linkerd.io/2021/12/29/the-service-mesh-in-2022/）。

Deislabs 的项目

Akri

Akri 是云原生计算基金会 (CNCF) 的一个沙盒项目，用于为 Kubernetes 提供边缘计算解决方案。Akri 旨在成为在边缘的 Kubernetes 集群上使用物联网设备的标准方式，这就是为什么 Akri 在希腊语中不仅意味着“边缘”，而且还代表 Kubernetes 资源接口。

Krustlet

Krustlet 是一种 kubelet 实现，使用户能够在同一个 Kubernetes 集群中运行 WebAssembly 和传统容器工作负载。

在 2021 年，Krustlet 和 krator 项目（Kubernetes Rust 状态机操作框架）一起成为了 CNCF 的沙盒项目，到目前为止，已经发布了 1.0-alpha.1 版本，1.0 正式版本即将发布。

那么，这个 1.0 究竟意味着什么？它意味着稳定性和向后兼容性保证。人们就可以开始用它构建一些真正的产品了。随着 WebAssembly 和 WASI 的成熟，后面还会添加更多功能。

WebAssembly ServerSide 与边缘计算

Lucet

在 Fastly 2021 回顾文章中提到：

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 by the end of 2022.

2021 年，Compute@Edge 的每日请求流量经历了爆炸性的增长，比 1 月份的每日流量暴涨了 31,000% 以上。客户使用量有望在 2021 年达到 2 万亿次总请求，目标是在 2022 年底达到 50 万亿次。

而这个 Compute@Edge 是 Fastly 的边缘计算平台，它能够运行你在自己的系统上编译并上传到 Fastly 的自定义二进制文件。通过将代码编译到 WebAssembly 来提供安全性和可移植性，他们使用 Lucet 在边缘运行它，Lucet 是由 Fastly 创建的开源 WebAssembly 运行时。而 Lucet 是基于字节码联盟的 wasmtime WebAssembly 运行时来实现的。

其他

在 WebAssembly Serverside 领域，还有很多极具创新的产品：

WasmEdge，是用于边缘计算和软件定义车辆的轻量级、快速和任务关键型代码 runtime 。目标是大幅降低复杂性并提高开发速度。它是目前市场上最快的 Wasm 虚拟机，由 Cpp 开发，但是现在正在开发 Rust SDK，会全面拥抱 Rust。
WasmCloud，是一个基于 WebAssembly 的分布式计算平台，目前也是 CNCF 沙盒项目。比较有创新的地方在于，它制定了一个 waPC 标准，用于 Guest 和 Host 的安全过程调用，来解决当前 WASI 等特性不完善的问题。

字节跳动的飞书、安全部门、基础设施部门都已经用上了 Rust ，并且还开源了一些基础库。其中比较出色的可用于云原生项目的有：

monoio，是一个基于 io-uring 的 Thread-per-core 模型的异步 Runtime，详细介绍参见:《Rust 异步运行时的设计与实现》https://rustmagazine.github.io/rust_magazine_2021/chapter_12/monoio.html
keyhouse ，字节内部使用的密钥管理系统已经在 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 已经 1.0
嵌入式异步框架 Embassy 正在大力开发且支持 STM32，nRF 和 RP2040 平台，并且还深深影响着 Rust 异步的改进
嵌入式开发和调试工具 Knurling 又发布了新的探针工具
嵌入式 TCP/IP 栈 smoltcp 发布了新版本
嵌入式图形库 embedded-graphics 发布了新版本
新的嵌入式实时 OS Hubirs 开源。

嵌入式工作组自身维护的项目在这一年也是大力开发和维护中。

更多参见: https://blog.rust-embedded.org/this-year-in-embedded-rust-2021/ 。

总的来说，Rust 在嵌入式领域越来越成熟了。

乐鑫芯片 (Espressif) esp-rs 进展

2021 年，乐鑫公司宣布雇佣 mabez 来全职从事 Rust 对 ESP32 的支持，对应 GitHub 开源组织是 esp-rs。这意味着，Rust 将全面进入 esp32 领域。

截止年底，mabez 完成的工作可以在其博客看到，总的来说目前进度为：

esp-rs book
probe-rs 对 esp32c3 的支持现在比较完善了
espflash 达到了 1.0
引入 esp32-hal
其他，还有很多

更多更新可以参见 Rust on Espressif chips - 10-01-2022 （https://mabez.dev/blog/posts/esp-rust-10-01-2022/）。不得不说，乐鑫是一家很有远见的公司。

趋势

ARM 是迄今为止在物联网边缘使用的芯片组和传感器等嵌入式设备的领先制造商，今年已经加入了 Rust 基金会。

Rust 完全有能力在嵌入式计算等更高级别的物联网领域完成特定任务，例如边缘轻量级计算和后端服务的实现，并同时可以在一定程度上满足这类物联网基础设施的功能安全需求。

由于其生态系统与物联网相关的部分，仍在不断发展，甚至缺乏一些重要的基础，而且远非稳定。但从好的方面来说，我们看到像 Drogue、Ferrous Systems 和其他独立的几家公司正在努力推动 Rust 进入物联网领域而对至关重要的基础正在进行积极的开发，并为 Rust 带来更光明的未来。

游戏

GPU 图形渲染值得关注的项目

rust-gpu

rust-gpu 是 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。

Rust-CUDA

Rust-CUDA 则是一个旨在使 Rust 成为使用 CUDA 工具包进行极快 GPU 计算的 1 级（tier-1）语言的项目。该团队希望通过这个项目，可以推动 Rust GPU 计算行业向前发展，并使 Rust 成为此类任务的优秀语言。Rust 提供了很多好处，例如高效利用每个内核的性能优势、出色的模块 /crate 系统、用 unsafe 分隔 CPU/GPU 代码的不安全区域、为底层 CUDA 库构建高级包装器等。

WGpu

gfx-rs 社区的目标是让 Rust 中的图形编程变得简单、快速和可靠。主要项目有：

wgpu，建立在wgpu-hal和naga之上。它为图形应用程序提供安全性、可访问性和可移植性。
naga，着色器语言翻译库，包括 WGSL。它还提供着色器验证和转换，确保在 GPU 上运行的用户代码安全高效。

其中 wgpu 2021 年发展：

gfx-hal 迁移到新创建的wgpu-hal并重组了存储库以将所有内容放在一起。
wgpu与Deno紧密集成。
正确性和可移植性方面，完成了确保所有资源正确零初始化的艰巨工作。事实证明，这比看起来要复杂得多，现在用户将获得跨平台的一致行为。

Naga 2021 年发展：

增加了更多的后端（HLSL、WGSL）并极大地改进了对桌面的支持
放弃了 SPIRV-Cross

游戏引擎中的佼佼者

Bevy

Bevy 是一个基于 Rust 实现的数据驱动游戏引擎。相比于 Rust 实现的其他游戏引擎，比如 Amethyst， Bevy 属于后来着居上。Bevy 在 API 设计方面独具匠心，充分利用 Rust 语言特点，让开发者上手非常简单方便。得力于其 Plugin 机制，目前 Bevy 已经逐渐形成自己的生态，逐步涌现出很多基于 Bevy 的 Plugin 。

Bevy 作为开源项目，在 GitHub 上接受的赞助现在基本已经达成了每月 6000 美刀的目标。虽然目前 Bevy 只发布了 0.6 版本，但是其生态在逐步建立，并且受到很多人的欢迎和期许。Bevy 0.6 版本中有大量改进、错误修复和质量提升，这里罗列一部分：

一个全新的现代渲染器，更漂亮、更快、更易于扩展
原生 WebGL2 支持。您可以通过在浏览器中运行 Bevy 示例来测试它！
更强大的着色器：预处理器、导入、WGSL 支持
Bevy ECS 人体工程学和性能改进。没有了.system()!

更多参见 Bevy 0.6 （https://bevyengine.org/news/bevy-0-6/）介绍。

Fyrox(Rg3d)

Fyrox(rg3d) 是另一款 Rust 实现的游戏引擎，支持 3D 和 2D ，之前项目名为 rg3d，现在已经改名为 Fyrox 。

该游戏引擎虽然没有 bevy 那样受人关注，但也在高速发展中，目前已经发布了 0.24 版本。简单来说的变化：

2d 支持。从一开始，引擎只专注于 3D 游戏，但在 rg3d 0.23 中情况发生了一些变化，
添加了一个简单的 2D 场景版本。
增加了开发指南
物理集成
引入了声音引擎 rg3d-sound

详细参见 rg3d 0.24 功能亮点（https://rg3d.rs/general/2022/01/07/0.24-feature-highlights.html）

Amethyst 新的开始

Amethyst 引擎宣布停止开发，游戏引擎的火炬传递给了 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 游戏开发领域去做更具价值的事。

Quilkin

quilkin 是 Google Cloud 与 Embark工作室合作开发的一个UDP代理，为高性能的实时多人游戏量身定做，以提供一个标准的、开源的解决方案。其目的有两个方面：

将安全、访问控制、遥测和指标等通用功能从单体的专用游戏服务器和客户端中剥离出来。
以一种可组合和可配置的方式提供这些通用功能，这样它就可以在广泛的多人游戏中重复使用。

总的来说，是让 Quilkin 通过吸收无效流量来帮助保护服务器免受攻击，或者在边缘运行为玩家流量提供最佳延迟。这对于任何游戏工作室都是利好，可以据此拥有与大型巨头相同的网络功能。

数据处理

Databend 数据云

Databend 旨在成为一个开源的弹性和可靠的云仓库，它提供了极快的查询，并结合了云的弹性、简单性和低成本，旨在使数据云变得简单。

Databend 受 ClickHouse 启发，计算模型基于 apache-arrow。Databend 实现了弹性的完全面向云架构的设计，它强调状态和计算的分离。相比传统数仓，用户使用 Databend 会获得更低成本、更易用、按量付费的体验。Databend 会向着 Serverless 方向迭代。Serverless 意味着把资源的调度做到更加精细化，云数据库的计算结点可以和一个函数一样，使用的时候拉起，使用完毕后销毁，只需要用使用付费，资源调度会非常精确。

数据流处理

Tremor

Tremor 是一个事件处理系统。它最初是为了替代 Logstash 或 Telegraf 等软件而设计的。然而，通过支持更复杂的工作流（例如聚合、汇总、ETL 语言和查询语言），tremor 已经超出了这个单一用例的范围。

Tremor 每年 365 天 24x7 运行，并使用 Rust 编程语言实现。

深挖了一下 tremor-runtime 项目背后的公司，原来是 Wayfair 。Wayfair 是美国最大的家具电商，2017 年市值就达 58 亿美元，前身是早在 2002 年就成立的 CNSStores。亚马逊都吃不下它。

Tremor 应该是 Wayfair 公司旗下的开源项目，已经进入 CNCF 。2021 年九月份还召开了一次小型的线上的 Tremor Conf

2020 年 3 月份的一次分享：Rust 如何为 Wayfair 省掉数千个核心和 TB 级的内存的成本：2020-03-31-RustAndTellBerlin-functions

从 2018 年开始， tremor 就是跑在了 wayfair 生产环境中，每天处理 10 兆字节的数据，或每分钟 100 亿条消息，每秒 1000 万个指标。tremor 降低了成本，减少了复杂性，巩固和简化了操作环境，以激发 SRE 的乐趣，减少 NOC 的工作量，并降低运营成本。

实时分析的流式数据库 Materialize

Materialize 是一个提供增量视图更新的反应式数据库，它帮助开发人员使用标准 SQL 轻松构建流数据。在无需复杂的数据管道的情况下，只须用标准 SQL 视图描述计算，然后将 Materialize 连接到数据流，就能实现增量计算。底层的差异数据流引擎（相关论文 Online Analysis of Distributed Dataflows with Timely Dataflow）能够执行增量计算，以最小的延迟提供一致且正确的输出。与传统数据库不同，定义 Materialize 的视图没有任何限制，并且计算是实时执行的。

该公司已经进入 B 轮，融资 4000 万美刀。

其他