写作者、教育者、讲者、翻译者、插画师等，努力帮助更多人理解和使用这套基础设施，甚至加入改进它；
长期投资这个项目的机构，他们提供维持数十年开发所需的资金和支持。
他们共同关注的，是“基础设施”。
01
基础设施
编程语言本身就是一种技术基础设施，Rust 则是一种帮助人们搭建其他基础设施的工具，比如网络协议、Web 服务器、负载均衡器、遥测系统、数据库、编解码器、加密系统、文件系统、操作系统、虚拟机、解释器……等等等等。
与其去争论 Rust 是否属于“系统级编程语言”的定义边界，我更愿意从“基础设施”这个角度理解 Rust 的定位。Deb Chachra 在她那本讲物理基础设施的书中说得很对：
“一个基础设施系统越是强大可靠，我们就越不去在意它，反而能把时间和注意力投入到别的事情上。”
“一个基础设施系统越是强大可靠，我们就越不去在意它，反而能把时间和注意力投入到别的事情上。”
这正是 Rust 最擅长构建的系统本质：不是炫酷抢眼，也不需要时刻引起关注，而是默默在后台稳定运行，让我们能够安心处理其他事，因为我们知道它不会出问题。
但 Chachra 也提醒过：
“基础设施最容易被看见的时刻，就是它出故障的时候。”
“基础设施最容易被看见的时刻，就是它出故障的时候。”
Rust 的实现、持续投入、以及如今令人惊叹的受欢迎程度，其实都源于我们对强大可靠基础设施的迫切需求——而我们原本所依赖的工具和系统，很多时候是靠不住的。说白了：它们经常出故障，不仅代价高昂，还容易造成安全漏洞。虽然当时也有很多效率很高的“造基础设施”用的语言，但那些语言太难用了，尤其是做并发编程时，几乎不可能写得安全。
这导致了一个不断扩大的“基础设施赤字”——尽管很多人说不上具体问题在哪儿，但大家都能感受到它的存在。与此同时，我们又对计算机提出了越来越多、越来越复杂的需求。摩尔定律逐渐触顶，多核系统、大量嵌入式和低功耗 IoT 系统快速增长，一切都接入了互联网，也都变得更容易被攻击。我们构建基础设施的软件工具已经越来越不堪重负，而且问题的根源，很大程度上就在于这些构建工具本身。
从这个角度来看，Rust 的机会其实很清晰。我们这些身处开发一线的人，都深刻体会到问题所在，也迫切希望能有更好的工具。很多人曾接触过函数式编程或其他学术语言，多少尝到了更好世界的味道，但现实是，我们只能用手头已有的工具。
02
投入
我们之所以只能用旧工具，是因为要造出像 Rust 这样的新工具，需要投入大量时间、精力和资金。我最初写的那个“引导版” Rust 编译器也就几万行代码，这几乎是一个没经费的个人项目能做到的极限了。
Mozilla 在 2009 年决定投资 Rust，直接让团队规模翻了四倍（之前其实还没有正式的团队），此后又连续数年不断扩张。Mozilla 从 2009 到 2020 年持续投入 Rust，这是非常少见、非常不容易的一种长期投入。同时他们还从 2012 年起资助了整个基于 Rust 编写的浏览器引擎 Servo，这不仅是一款产品，更是 Rust 语言功能的关键测试平台。光是这些项目，就有数十位工程师全职干了将近十年。
当然，不只是 Mozilla 在贡献。举几个例子：
Rust 构建于 LLVM 之上，而 LLVM 本身就是一个更大型的基础设施，最初由 UIUC 的研究人员开发，后续获得 Apple、Qualcomm、Google、ARM、华为等众多机构的资助；
Rust 的内存安全模型借鉴了几十年来的学术研究成果，以及像 Cyclone 这种由 AT&T 贝尔实验室和康奈尔大学主导的学术-工业合作项目；
Samsung 也曾参与 Rust 和 Servo 的开发，并将其视为战略项目；
来自 CMU、NEU、IU、MPI-SWS 等顶尖学术机构的实习生、研究者和教授也都做出了重要贡献；
到了 2020 年，Rust 需要更多元的资助来源，Amazon、Facebook、Google、Microsoft、华为等公司开始雇佣核心开发者，提供硬件资源和管理支持；
上述公司也加入了 Rust 基金会，为项目提供物理基础设施、法律支持、组织架构，以及各种长期资助；
JetBrains 和 Rust-Analyzer 的 OpenCollective 社群基本上资助了两个完整的增量式前端重构实现，为 IDE 提供语言服务，这对日常开发效率至关重要；
数百家企业和机构投入时间和资金评估 Rust，用 Rust 写程序、测试、报 bug，并雇佣员工解决问题或改进功能；
最重要的一点：有成千上万名志愿者，投入数年时间为项目无偿工作。虽然表面上看是“免费”的，但其实这些劳动只是没有体现在企业财报里而已。
Rust 构建于 LLVM 之上，而 LLVM 本身就是一个更大型的基础设施，最初由 UIUC 的研究人员开发，后续获得 Apple、Qualcomm、Google、ARM、华为等众多机构的资助；
Rust 的内存安全模型借鉴了几十年来的学术研究成果，以及像 Cyclone 这种由 AT&T 贝尔实验室和康奈尔大学主导的学术-工业合作项目；
Samsung 也曾参与 Rust 和 Servo 的开发，并将其视为战略项目；
来自 CMU、NEU、IU、MPI-SWS 等顶尖学术机构的实习生、研究者和教授也都做出了重要贡献；
到了 2020 年，Rust 需要更多元的资助来源，Amazon、Facebook、Google、Microsoft、华为等公司开始雇佣核心开发者，提供硬件资源和管理支持；
上述公司也加入了 Rust 基金会，为项目提供物理基础设施、法律支持、组织架构，以及各种长期资助；
JetBrains 和 Rust-Analyzer 的 OpenCollective 社群基本上资助了两个完整的增量式前端重构实现，为 IDE 提供语言服务，这对日常开发效率至关重要；
数百家企业和机构投入时间和资金评估 Rust，用 Rust 写程序、测试、报 bug，并雇佣员工解决问题或改进功能；
最重要的一点：有成千上万名志愿者，投入数年时间为项目无偿工作。虽然表面上看是“免费”的，但其实这些劳动只是没有体现在企业财报里而已。
尽管周期漫长，但所有这些投入，最终都得到了回报。我们每个人都从中受益。
03
回顾过去
2006–2009 年我写的早期版本 Rust，几乎没有类型检查器，生成的代码极其缓慢，只能运行在三个平台上（实际上都是 32 位 x86 架构，可以说只有一个），连最基本的 IO 操作和小型测试都几乎跑不起来。2011 年的引导编译（bootstrap）甚至要耗费几个小时。
到了 2015 年发布 1.0 时，Rust 已被彻底重构，参与者众多，几乎已认不出这还是原来的语言。它具备由一流专家打造的多态类型系统，性能上足以稳定胜过 C++，支持大多数主流 LLVM 平台，甚至已经能用来写一个相当像样的网页渲染引擎了。
但回过头看，Rust 1.0 相较今天依然相当原始。虽然它号称“可用于生产”（或者说“稳定”），但还远远谈不上“主流就绪”。它缺乏：
完善的 IDE 开发体验：1.0 时只能依赖当时还很新的 racer 自动补全工具，而现在的 Rust 已默认配备工业级语言服务器 rust-analyzer。
丰富的包生态与成熟的包管理工具 cargo：1.0 发布时，crates.io 上大约只有 2000 个 crate，cargo 也仅诞生 6 个月，代码量仅 1.4 万行。而如今 cargo 已超 9 万行，成为各类包管理器的标杆，crates.io 的 crate 数已超过 18 万。
标准化的高性能 IO 和网络库支持：现在的 Rust 程序擅长处理高并发网络流量，但在 1.0 时还没有 async/await 语法支持，更没有 Tokio 这样的异步运行时。
众多提升开发体验的语言功能：从传播错误的 ?操作符，到模式匹配和模块系统中的易用性优化，如今的 Rust 编程体验已经大不相同。而 Rust 最引以为傲的编译错误提示系统，也让全世界其他语言羡慕不已。
语言规范的确立：直到最近才有 FLS（Rust 的语言语义规范）以及即将推出的官方语言规范。当时对 unsafe代码的定义几乎一片空白——RustBelt 项目和 MIRI 解释器填补了这一空白。
MIR 的缺失：当时编译器的中间阶段是直接在抽象语法树（AST）上操作，然后直接降到 LLVM。这使得许多优化、错误分析，甚至一些非常重要的特性几乎无法实现。从常量求值到非词法作用域生命周期（NLL），都依赖于向 MIR 的转变。
完善的 IDE 开发体验：1.0 时只能依赖当时还很新的 racer 自动补全工具，而现在的 Rust 已默认配备工业级语言服务器 rust-analyzer。
丰富的包生态与成熟的包管理工具 cargo：1.0 发布时，crates.io 上大约只有 2000 个 crate，cargo 也仅诞生 6 个月，代码量仅 1.4 万行。而如今 cargo 已超 9 万行，成为各类包管理器的标杆，crates.io 的 crate 数已超过 18 万。
标准化的高性能 IO 和网络库支持：现在的 Rust 程序擅长处理高并发网络流量，但在 1.0 时还没有 async/await 语法支持，更没有 Tokio 这样的异步运行时。
众多提升开发体验的语言功能：从传播错误的 ?操作符，到模式匹配和模块系统中的易用性优化，如今的 Rust 编程体验已经大不相同。而 Rust 最引以为傲的编译错误提示系统，也让全世界其他语言羡慕不已。
语言规范的确立：直到最近才有 FLS（Rust 的语言语义规范）以及即将推出的官方语言规范。当时对 unsafe代码的定义几乎一片空白——RustBelt 项目和 MIRI 解释器填补了这一空白。
MIR 的缺失：当时编译器的中间阶段是直接在抽象语法树（AST）上操作，然后直接降到 LLVM。这使得许多优化、错误分析，甚至一些非常重要的特性几乎无法实现。从常量求值到非词法作用域生命周期（NLL），都依赖于向 MIR 的转变。
标准库的飞跃式扩展：std 从 4 万行增长至 12 万行，core 从 1.5 万行增长至 7.9 万行，如今标准库的体量甚至超过了 1.0 时整个编译器的规模。每次发布都有新功能、API 改进、文档完善和语言演进的同步适配。
重要的一点：以上所有变化都发生在 1.0 之后的稳定期。每一项改动都通过了全面的测试，所有版本都进行了回归测试，覆盖了 crate 生态的广泛代码库。只要会破坏已有代码的变更，几乎都会被拒绝。Rust 实现了“稳定而不僵化”的承诺——大多数老代码至今还能稳健运行，像一套可靠的基础设施那样运转无误。
标准库的飞跃式扩展：std 从 4 万行增长至 12 万行，core 从 1.5 万行增长至 7.9 万行，如今标准库的体量甚至超过了 1.0 时整个编译器的规模。每次发布都有新功能、API 改进、文档完善和语言演进的同步适配。
重要的一点：以上所有变化都发生在 1.0 之后的稳定期。每一项改动都通过了全面的测试，所有版本都进行了回归测试，覆盖了 crate 生态的广泛代码库。只要会破坏已有代码的变更，几乎都会被拒绝。Rust 实现了“稳定而不僵化”的承诺——大多数老代码至今还能稳健运行，像一套可靠的基础设施那样运转无误。
04
数据一览
用一组数据来概括过去这十年 Rust 项目在“不断进化但不破坏旧代码”的原则下所做的努力：
1.0 之前，Rust 代码库累计了 4 万次提交；此后又新增了 24.6 万次提交。换算下来，过去 10 年几乎是每小时合并 2.8 次提交。
贡献者从 1.0 时不足 1000 人，扩展到现在约 6700 人。
项目已关闭超过 4.7 万个 issue，合并了 14 万多个 PR。
1.0 时共计约 1100 份 RFC（用于语言演进的提案），如今累计达到了 3772 份。
发布了 87 个正式版本，大多数都按六周节奏准时发布。
推出过 3 个 Edition（版本变更打包，兼容旧代码），用于引入需要 opt-in 的非兼容变更。
每个版本的兼容性测试范围从 2500 个 crate 增长到了现在的 58.7 万个。
1.0 之前，Rust 代码库累计了 4 万次提交；此后又新增了 24.6 万次提交。换算下来，过去 10 年几乎是每小时合并 2.8 次提交。
贡献者从 1.0 时不足 1000 人，扩展到现在约 6700 人。
项目已关闭超过 4.7 万个 issue，合并了 14 万多个 PR。
1.0 时共计约 1100 份 RFC（用于语言演进的提案），如今累计达到了 3772 份。
发布了 87 个正式版本，大多数都按六周节奏准时发布。
推出过 3 个 Edition（版本变更打包，兼容旧代码），用于引入需要 opt-in 的非兼容变更。
每个版本的兼容性测试范围从 2500 个 crate 增长到了现在的 58.7 万个。
而除了软件本身的演进，更重要的是围绕 Rust 建立起来的整个生态和社区：
出版了大量高质量图书，包括多次再版的《The Rust Programming Language》《Programming Rust》《Rust in Action》《Rust for Rustaceans》等，也有多语言翻译版本。
出版了大量高质量图书，包括多次再版的《The Rust Programming Language》《Programming Rust》《Rust in Action》《Rust for Rustaceans》等，也有多语言翻译版本。
教学内容遍地开花：从 Rust by Example、Rustlings 到 Google 推出的 Comprehensive Rust Course，学习资源比 1.0 时代丰富了一个数量级。
项目治理结构持续完善：Rust 基金会已正式成立，持有商标和法律权利，并为关键资源如 crates.io 和集成测试基础设施提供人力和资金支持。
项目内部治理也经历多轮调整，目前采用的是“领导理事会”模式。
参与 Rust 生态的机构范围不断扩大，如今已经包括用于高安全性领域的软件标准制定组织，乃至部分国家政府机构。
教学内容遍地开花：从 Rust by Example、Rustlings 到 Google 推出的 Comprehensive Rust Course，学习资源比 1.0 时代丰富了一个数量级。
项目治理结构持续完善：Rust 基金会已正式成立，持有商标和法律权利，并为关键资源如 crates.io 和集成测试基础设施提供人力和资金支持。
项目内部治理也经历多轮调整，目前采用的是“领导理事会”模式。
参与 Rust 生态的机构范围不断扩大，如今已经包括用于高安全性领域的软件标准制定组织，乃至部分国家政府机构。
05
展望未来
Deb Chachra 曾说：
“此类系统的建设建立在一个核心信念之上——未来会有一个稳定的社区持续从中受益，通常是几十年。这是一种面向共同未来的投资，本质上关乎延续性与时间维度。更进一步，若能实现普遍可用，其价值也会因成本可在更大用户基础上摊销而进一步凸显。”
“此类系统的建设建立在一个核心信念之上——未来会有一个稳定的社区持续从中受益，通常是几十年。这是一种面向共同未来的投资，本质上关乎延续性与时间维度。更进一步，若能实现普遍可用，其价值也会因成本可在更大用户基础上摊销而进一步凸显。”
Rust 的今天，是那些具有远见的机构的长期投入，以及数千名开发者共同努力的结果。他们相信所构建的一切，最终将带来可观的长期回报。尽管 Rust 已经走过了 10 年（甚至 15 或 20 年），但别忘了，C++ 已经有 40 年历史，FORTRAN 更接近 70 年。Rust 完全有可能走得更远。
在思考 Rust 的未来时，我们需要关注以下几个关键点：
在这些年里，数以千计的贡献者中，有很多因为精力耗尽或生活与工作的冲突，不得不离开。我本人也只坚持了七年！虽然项目从一开始就努力构建包容性社区（比如早期的行为准则），但仍需要不断吸引、融入新成员，并做好维护者的代际交接。
对于支持机构也是一样。项目需要为每一代维护者提供稳定、多元的支持来源，尤其是能为有志从事 Rust 全职开发的人提供实际的岗位和保障。
项目未来很可能继续扩张。目前 Rust 在编程语言市场的占比约为 3%，随着使用规模不断扩大，势必还会遇到更多“扩展性瓶颈”。
随着生态不断扩大，Rust 项目的可靠性与兼容性也将面临更高要求。一旦出现错误，其影响的用户数量、代价及后果都将成倍上升，尤其是对那些把核心业务建立在 Rust 工具和代码上的机构来说更是如此。项目团队必须设定越来越高的质量门槛，确保每一个改动都经过充分验证，并征求所有相关方意见。这也意味着要持续投入在提升可靠性的技术上，包括那些基于 Rust 构建的新兴形式化验证工具。
当然，未来不是遥不可及的想象。即便是当下，Rust 项目也任务繁重：虽然已经关闭了超过 4.7 万个 issue，但仍有超过 1 万个未解决问题，每天还有新的问题被提出。3772 份 RFC 中，仍有大量尚未进入审查流程，几百项改动等待评审和合并，而每六周还需要发布一个新版本。
在这些年里，数以千计的贡献者中，有很多因为精力耗尽或生活与工作的冲突，不得不离开。我本人也只坚持了七年！虽然项目从一开始就努力构建包容性社区（比如早期的行为准则），但仍需要不断吸引、融入新成员，并做好维护者的代际交接。
对于支持机构也是一样。项目需要为每一代维护者提供稳定、多元的支持来源，尤其是能为有志从事 Rust 全职开发的人提供实际的岗位和保障。
项目未来很可能继续扩张。目前 Rust 在编程语言市场的占比约为 3%，随着使用规模不断扩大，势必还会遇到更多“扩展性瓶颈”。
随着生态不断扩大，Rust 项目的可靠性与兼容性也将面临更高要求。一旦出现错误，其影响的用户数量、代价及后果都将成倍上升，尤其是对那些把核心业务建立在 Rust 工具和代码上的机构来说更是如此。项目团队必须设定越来越高的质量门槛，确保每一个改动都经过充分验证，并征求所有相关方意见。这也意味着要持续投入在提升可靠性的技术上，包括那些基于 Rust 构建的新兴形式化验证工具。
当然，未来不是遥不可及的想象。即便是当下，Rust 项目也任务繁重：虽然已经关闭了超过 4.7 万个 issue，但仍有超过 1 万个未解决问题，每天还有新的问题被提出。3772 份 RFC 中，仍有大量尚未进入审查流程，几百项改动等待评审和合并，而每六周还需要发布一个新版本。
如此持续、高效、有序的开发节奏，本身就是一个奇迹。Rust 项目为现代工具链、流程管理与基础设施软件设立了新的标杆。所有参与者都应该为这份成就感到自豪。
最后，特别感谢 C.S. Tysor 对这篇文章早期版本的反馈支持。返回搜狐，查看更多