一次电梯故障，催生出大厂最爱的语言：Rust稳定版迎来十周年！

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

2025 年 5 月 15 日，Rust 首个稳定版发布迎来了 10 周年。作为一门现代系统编程语言，Rust 兼具内存安全和高性能，允许开发者写出快速、高效、可靠的程序。它的核心亮点在于“所有权”模型——这套机制能在编译阶段就帮你排除一大批常见 bug，比如数据竞争、空指针等，而且不需要垃圾回收器。因此，Rust 特别适合用于性能要求极高的场景，比如操作系统、游戏引擎、浏览器等。

如今 Rust 已经成了全球最火的编程语言之一。微软、亚马逊都认为它是未来的关键技术，同时 Discord 就用 Rust 来提升性能、Dropbox 用它同步文件、Cloudflare 用 Rust 处理了全球 20% 以上的网络流量，连美国政府也在大力推广用 Rust 写软件，说这样能让系统更安全。

殊不知，回看 Rust 的诞生，起点可以说相当“接地气”。

2006 年，Graydon Hoare 这一年 29 岁，是 Mozilla 浏览器公司的程序员。有一天他下班回到温哥华的公寓，结果发现电梯又坏了——原因是系统崩溃了，而且不是第一次了。

他住在 21 楼，只能硬着头皮爬楼梯。一边爬，一边越想越气：“我们搞计算机的，居然连个不会崩溃的电梯程序都做不出来，简直离谱。”

他很清楚，这类故障常常是内存管理出问题。像电梯这种嵌入式设备里，软件大多是用 C 或 C++ 写的。这类语言运行快、占空间小，但也容易出错，尤其是容易引入“内存漏洞”——只要处理不当，程序就会直接崩溃。

微软曾经统计过，它自家代码中高达 70% 的漏洞，都和 C/C++ 写的内存管理有关。

大多数人可能就是骂几句了事，但 Hoare 决定做点什么。他回到家，打开笔记本，开始设计一门新语言。他想要一种既能写出小而快的程序，又能在根本上避免内存 bug 的语言。

他给这门语言起名叫 Rust，灵感来自一种非常顽强的真菌——在他眼里，这个名字意味着“为生存而过度设计”。

时下，正值 Rust 稳定版迎来 10 周年之际，Rust 基金会官方博客最新分享了一篇来自 Rust 编程语言作者 Graydon Hoare 撰写的博文《10 Years of Stable Rust: An Infrastructure Story》，以此庆祝。博文中，Graydon Hoare 回顾了 Rust 的诞生历程，也将其视为一种基础设施。

以下为其发布的全文：

Rust 今天 10 岁了——准确来说，是它的 1.0 正式发布已经过去了整整 10 年。在这十年中（以及发布前近十年的开发期），Rust 的成长和变化几乎超出了我的理解范围。如果说我对它的发展轨迹感到惊讶，那就太轻描淡写了。我只能衷心感谢、祝贺并赞美所有参与其中的人。能在这些年里见证 Rust 的一切，并从今天的角度回望这一切，实在令人深受鼓舞。

虽然我们很容易将 Rust 的旅程归结为一个“理念”的发展——比如从我 2006 年在一部坏掉的电梯里沮丧而滑稽的灵感开始，这在 MIT Technology Review 的一篇文章中有详细记载（https://www.technologyreview.com/2023/02/14/1067869/rust-worlds-fastest-growing-programming-language/）——但我认为，如果只这么讲，那就忽略了更宏大的图景。

在我看来，Rust 是一个关于广大利益相关者如何齐心协力，设计、构建、维护并扩展共享技术基础设施的故事。这是一个由许多参与者共同谱写的故事：

• 使用该语言的开发者群体，他们通过讨论、争论、测试和 bug 报告表达自己的需求和约束——这些都来源于他们编写库和应用程序的实际经验。

• 语言的设计者与实现者，他们在努力满足这些需求与约束的同时，还要面对每一个设计决策所带来的意外后果。

• 作家、教育者、讲者、翻译者、插画师以及其他各类传播者，他们让更多人能够使用和贡献这一基础设施。

• 对项目进行长期投资的机构，它们为持续多年的工作提供了所需的资金与支持。

所有这些角色，都围绕着同一个核心——基础设施。

基础设施

编程语言是一种技术基础设施：它们是工具。Rust 是一种构建其他基础设施的工具，比如网络协议、Web 服务器、负载均衡器、遥测系统、数据库、编解码器、密码学工具、文件系统、操作系统、虚拟机、解释器等等。

我认为，与其去争论 Rust 是否“属于系统编程语言”的边界，不如将它看作是一种“基础设施工具”，这种视角更为有用。正如 Deb Chachra 在她那本关于物理基础设施的出色著作中写道：

“我们的基础设施系统越强大、越可靠，我们考虑的东西就越少，我们投入到其他事务上的时间和精力就越多。”

这正是 Rust 最擅长承载的系统类型：它们不是华而不实，也不博人眼球，甚至往往悄无声息。但它们稳健、可靠，是支撑其他工作顺利开展的必需品。它们应当如水电般存在——我们理应相信它们会在背后安静运行，丝毫不扰。

然而，正如 Chachra 同样指出的那样：“基础设施最引人注目的时刻，往往是它出故障的时候。”

Rust 的最初实现、持续投资以及令人难以置信的传播速度与接受度，都源于世界对稳健可靠基础设施的需求——而当时我们已有的基础设施明显不够好。简单来说：它们太容易出问题，代价太昂贵。最轻的代价是崩溃和宕机，最严重的是安全漏洞。虽然当时已经有一些高效的“基础设施构建语言”，但它们难以使用，尤其是在写并发代码时几乎不可能做到安全。

这种差距让人们深切感受到“基础设施赤字”的存在，尽管并非每个人都能准确指出它的本质。与此同时，我们对计算的期望与日俱增：摩尔定律开始趋于停滞，多核系统日益普及，低功耗嵌入式设备和物联网迅速扩张，一切设备也越来越频繁地接入互联网、暴露在攻击之下。基础设施软件不堪重负，而构建它的工具——显然已成为罪魁祸首之一。

从这个视角来看，Rust 的机会其实非常明确。我们这些身处其中的人对此感同身受，渴望更好的工具。我们中的许多人曾用过函数式语言或研究型语言，体验过“更好世界的一角”，但却被现实中的工具所困。

投资

我们之所以被当时已有的工具所限制，是因为构建像 Rust 这样更好的工具，需要投入大量的时间、精力和资金。我最初写的 Rust 引导编译器只有几万行代码；这已经接近一个没有资金支持的业余项目所能达到的极限。

2009 年，Mozilla 决定投资 Rust，这一决定立刻让团队规模扩大了四倍——实际上，这个决定才算真正组建了一个团队。

之后数年，团队规模又接连翻倍。Mozilla 从 2009 年到 2020 年持续投入 Rust，这是一个极为罕见、极不寻常的长期投资。同时，Mozilla 还自 2012 年起资助了用 Rust 编写的完整浏览器引擎 Servo，后者也成为 Rust 语言功能的关键试验平台。这两个项目有几十位工程师参与，持续奋战了整整十年。

而且，投入者远不止 Mozilla。以下是一些例子：

• Rust 构建于 LLVM 之上，后者是更大型的通用技术基础设施，最初由伊利诺伊大学厄巴纳-香槟分校的研究人员开发，后来得到了 Apple、Qualcomm、Google、ARM、华为等众多机构的资助。

• Rust 的内存安全模型直接继承自数十年的学术研究成果，以及一些学术-工业合作项目，如 AT&T 贝尔实验室和康奈尔大学共同开发的 Cyclone 项目。

• Rust 和 Servo 项目在三星也有多位贡献者，反映出该公司对这些项目的战略兴趣。

• 来自顶尖编程语言研究院系（如 CMU、NEU、IU、MPI-SWS 等）的实习生、研究人员和教授，也在业余时间为 Rust 做出大量贡献。

• 到了 2020 年，为了获得更多元的资金支持，其他公司也加入了进来。Amazon、Facebook、Google、Microsoft、华为等雇佣了核心开发者，并提供硬件和管理资源，助力项目持续发展。

• 这些公司以及其他许多机构还加入了 Rust 基金会，资助物理基础设施、法律与组织结构建设，提供项目补助与长期战略支持。

• JetBrains 和 Rust-Analyzer 的 OpenCollective 社群基本上资助了两套增量式交互前端的重构实现，为 IDE 提供语言服务——这是现代开发中不可或缺的关键工具。

• 数百家公司和机构也投入时间和金钱评估 Rust 是否可用于生产环境，编写 Rust 程序，测试它们，提交 bug，并资助员工修复或改进问题。

• 最后但绝非最不重要的是：成千上万的志愿者为这个项目无偿付出多年。虽然从表面上看似乎是“免费”的，但这也是有代价的——只是不像企业预算那样显性。

尽管这是一项长期投资，但它确实得到了回报。我们所有人都从中受益。

回顾过去

我在 2006–2009 年间写的“婴儿版” Rust 几乎没有类型检查功能，生成的代码速度极慢，只能在三个平台上运行（其实都是 32 位 x86，说白了就是一个平台），几乎无法进行基本的 IO 操作或运行简单的演示测试。当时的引导编译要花上好几个小时。

到了 2015 年发布 1.0 时，Rust 已经被彻底改造，来自无数人的努力让它几乎不再是原来的语言。它拥有由世界顶级专家设计的多态类型系统，性能好到可以与 C++ 一较高下，支持大多数主流 LLVM 平台，甚至可以用它写出一个功能相当可观的浏览器引擎。

但即便如此，Rust 1.0 以今天的标准来看，依然显得相当“原始”。虽然它在当时已“可用于生产”（或者说“稳定”），但距离真正“走向主流”还差得远。它当时还缺乏：

• 高质量的 IDE 体验。Rust 1.0 用户当时只能使用新出的自动补全工具，而今天的 Rust 则配备了工业级的 LSP 语言服务器 rust-analyzer。

• 庞大的包生态与成熟的 cargo 工具。1.0 时，crates.io 上仅有约 2000 个 crate，cargo 还很新——发布才半年，代码量仅约 1.4 万行。如今的 cargo 体积已增长至六倍，成为衡量所有包管理器的新标杆，crates.io 也已拥有超过 18 万个 crate。

• 高性能 IO 或网络的标准解决方案。如今 Rust 在网络流量处理方面表现极佳，但在 1.0 时，语言机制和如 Tokio 这类运行时尚未问世，async/await也尚未引入。

• 大量语言层面提升开发体验的改进。例如 ? 运算符用于简化错误传递、模式匹配语法改进、模块系统优化等等，大幅提升了日常编码的可读性与可维护性。而 Rust 著名的错误信息提示，更是所有语言竞相效仿的典范。

• 正式的语言规范，如近期通过的 FLS（以及即将发布的正式规范）。尤其是在 unsafe 语义方面，Rust 1.0 没有任何描述代码含义或其正确性边界的说明，这方面如今已有 RustBelt 项目和 MIRI 解释器来补足。

• MIR 中间表示完全不存在！当时编译器直接从 AST 降级为 LLVM IR，导致很多优化、错误分析，甚至一些核心功能几乎无法实现。从 const 求值到非词法生命周期，全都依赖 MIR 的引入。

• 核心库的显著扩展。核心库代码从约 4 万行增长到 12 万行，标准库从 1.5 万行扩展到 7.9 万行——如今它们的体量已经超过了 Rust 1.0 时整个编译器的体积！每个版本都带来了新特性、API 改进、文档完善和语言调整。

值得注意的是：这些变更全部发生在 1.0 发布之后，因此每一项都必须通过详尽的测试套件，每一个版本都需回归测试公开 crate 生态的一大部分，几乎所有破坏现有代码的更改都会被拒绝。如 1.0 发布公告所承诺，Rust 实现了“稳定而不僵化”：旧代码几乎都能顺畅运行，如同优秀的基础设施应有的样子。

为了更直观地感受 Rust 在保持向后兼容的前提下，持续演进所带来的庞大变更量，我们可以来看一组具体数字：

• 在 1.0 发布之前，Rust 仓库中共记录了约 4 万次变更；而在此之后，又增加了 24.6 万次变更。换句话说，过去十年里，平均每小时有约 2.8 个变更合并，全年无休、昼夜不停。

• 参与贡献这个仓库的人数从 1.0 发布时的不到 1000 人增长到现在的约 6700 人。

• 这些贡献者一共提交了超过 14 万个 Pull Request，关闭了超过 4.7 万个 Issue。

• 在 1.0 时，用于提议和管理语言变更的 RFC（Request for Comments）约有 1100 个，而如今已经有 3772 个。

• 自 1.0 发布以来，Rust 社区共完成了 87 个完整的发布周期，几乎都是每六周按时发布。

• 此外，还有 3 个主要版本（edition）发布，这些版本将一批不兼容变更打包，以“仅影响 opt-in 的 crate”的方式进行切换，从而不破坏现有代码。

• 每个版本发布前会运行的生态兼容性测试，也从 1.0 时针对约 2500 个 crate，扩大到了如今的 约 58.7 万个 crate。

虽然 Rust 在软件层面的种种变革令人印象深刻，但同样值得称道的，是它在软件之外所经历的一系列重要转变。正是这些变化，确保了 Rust 能真正承担起服务社区的基础设施角色：

• 诞生了大量与 Rust 相关的书籍，许多是由受雇于 Rust 项目的工程师在工作时间内完成的。《The Rust Programming Language》《Programming Rust》《Rust In Action》《Rust for Rustaceans》等新版图书不断出版，并被翻译成多种语言，填满了世界各地的书架。

• 教学资源也迅速增长。从《Rust By Example》和《Rustlings》到 Google 出品的《Comprehensive Rust Course》，自 1.0 以来，Rust 学习材料的数量与质量都实现了爆发式提升。

• Rust 项目在组织与运营层面也做了大量工作：Rust 基金会作为独立的法律和财务实体成立，接手了包括商标在内的关键法律权益，并为项目提供日常运营支持与重要资源的管理，如集成测试基础设施和 crates.io。

• 与此同时，项目的内部治理结构也经历了多轮重组，最终形成了如今的“领导委员会”体系。

• 参与 Rust 项目指导、倡导与需求制定的利益相关者和机构数量大幅增长，如今其中已包括涉及安全关键软件工业标准的组织，甚至还有国家政府与相关机构。

展望未来

再次引用 Deb Chachra 的话：

“首先，构建这类系统的前提，是相信未来几十年会有一个稳定的社区从中受益。这是一种对共同未来的投资，本质上关乎延续性和时间。其次，若能为所有人普遍提供这类系统，其经济价值也会随之增强——因为建设和运营成本可以在更多用户之间摊销。”

Rust 发展至今，是无数具有前瞻性的机构和成千上万相信“长期回报”的个人共同努力的成果。虽然 Rust 已经存在了 10 年（甚至可以追溯到 15 或 20 年前），但 C++ 已走过 40 年，FORTRAN 更接近 70 年。Rust 完全有可能拥有同样长，甚至更长的生命力。

因此，在思考 Rust 的未来时，有几个重点值得关注：

• 在这十年间，数以千计的贡献者中，很多人由于精疲力竭或其他事务缠身，不得不逐步淡出。我自己也只坚持了 7 年！虽然 Rust 项目自早期就通过行为准则等方式致力于建设一个广泛包容的社区，但仍需要持续投入精力来吸引和融入新成员，同时也要妥善完成每一代维护者的交接工作。

• 对于资助机构而言，情况也是一样。Rust 项目需要尽可能保障每一代维护者都能获得稳定、多元的支持来源，并在理想情况下，为希望长期从事 Rust 开发的人提供全职工作机会。

• 项目很可能还会持续扩张。目前 Rust 在编程语言市场中约占 3%，随着规模的扩大，必然会面临更多扩展性挑战。例如：Cargo 近期花了大量时间设计全新的稀疏索引协议，仅仅是因为原来的索引数据已庞大到 git 无法高效处理。甚至连项目的团队目录都复杂到需要专门的管理工具。

• 随着项目规模增长，保障稳定性与兼容性将变得更为关键。任何错误带来的代价和影响人群都会增加，尤其是那些将自身业务运行建立在 Rust 工具和代码之上的机构，其风险容忍度极低。项目必须以更高的标准来要求自己——确保每一次改动都正确无误，并充分征求所有可能相关方的意见。这还应包括在可靠性技术上的投入，比如当前正在 Rust 基础上构建的多个形式化方法项目。

当然，无需等到未来才能看出 Rust 的任务清单有多庞大。项目当前已经“任务满满”了！虽然已有 4.7 万个 issue 被关闭，但仍有超过 1 万个尚未解决，每天都有新的问题被提出。3,772 个 RFC 中也还有不少处于开放状态，等待关注；成百上千项变更正处于评审与合并流程中；每六周，还需要发布一个全新的稳定版本。

这一系列持续、有序、令人惊叹的工作流，本身就是一个奇迹。Rust 项目为“什么是优秀的工具、优秀的流程、优秀的软件基础设施”树立了全新标准。所有参与其中的人，都理应为他们的成就感到自豪。

原文：https://rustfoundation.org/media/10-years-of-stable-rust-an-infrastructure-story/

https://www.technologyreview.com/2023/02/14/1067869/rust-worlds-fastest-growing-programming-language/

---