作者：Alec Mocatta，Tably 创始人
时间：2025年6月1日
我是在 2015 年 6 月写下第一行 Rust 代码的，那时 Rust 1.0 发布的热潮刚过一个月。彼时我从 C、Python 和 JavaScript 背景转来，从此再没回头。十年间，我参与了两个基于 Rust 的创业项目，累计写下 50 万行 Rust 代码，现在是时候回顾这个里程碑了。
最初的日子很痛苦
版本兼容性很差 ------ 无论是 crates（依赖包）之间，还是它们与编译器之间。一个小小的 bug 修复更新，可能就需要升级编译器，而新的编译器又可能依赖不稳定的 crates，比如当年的 syntex（它曾是 serde 的关键依赖），以及它们的下游依赖。实际开发中，我们常常不得不"更新整个世界"，并临时锁定版本，尤其在必须修复关键 bug 或使用某个功能时 ------ 而这在早期几乎每 6 周一次的编译器发行周期中都会发生。我们浪费了大量时间在二分查找兼容版本组合上。
"与借用检查器作战"对我而言是真实存在的。由于 C++、Java 和 Objective-C 的背景，Trait 的概念对我来说很自然，但生命周期和"证明"的概念（虽然大多不会影响代码生成）则让我花了一段时间去理解。幸运的是，有耐心的朋友和同事帮了我很大忙！
随着代码量和团队规模的增长，编译时间开始变得令人痛苦。大型类型是反复出现的问题（至今仍偶尔如此），需要排查并优化。虽然我们做了不少投入把编译时间降了下来，但迭代周期依然受限，快速原型开发往往也要预先做很多准备。
Rust 社区的开发者一直都很优秀
Rust 生态中的程序员具有令人惊叹的"编程品位"：依赖包构建简单、实现优雅、性能又快又稳。相比之下，回头使用 TypeScript 或 Python 简直是自讨苦吃。Rust 连续九年被评为"最受欢迎/最受敬佩的语言"并非偶然！
关于"Rust 成功的原因"，单独可以写一篇文章，但我认为最关键的，是一批坚定、有原则、真实投入的志愿者持续投入，他们敢于说"不"和"还不到时候"。
我作为雇主也深受其益。我们是伦敦为数不多的使用 Rust 的公司之一，吸引了很多优秀工程师，他们渴望用自己最爱的语言工作。而且，不得不说，一名普通 Rust 程序员的平均水平，往往高于绝大多数其他语言的程序员。
Rust 在部分领域已成为"稳妥的选择"
早期使用 Rust 意味着需要大量"刮胡子"（即修补生态缺口）。例如标准库中的缺失促使我们构建了不少 workaround、hack 和扩展代码 ------ 这些代码简化或优化了业务逻辑，但还不成熟、也不合适被合入上游。随着时间推移，我们构建这些自定义工具的速度慢了下来，反而开始从代码库中移除它们。再见了，定制实现！如今我们可以依赖标准库中越来越多的原语，即使是相对不常见或抽象的功能，也能享受良好性能，这实在太棒了。
这种可靠性已扩展到整个 Rust 开发体验：构建和升级变得极其可预测，依赖更少非 Rust 组件，几乎不会出现意外的编译时间、代码生成或内联崩溃，更少依赖 nightly 特性，更好地遵循了 semver（语义化版本控制）。推理能力的提升也让新手更容易适应借用检查器。而 nightly 构建中出现的内部编译错误（ICE）也从"每周一次"变成"每季度才见一次"。
crate 生态本身也更稳定了：像 jiff、polars、tauri 等新项目构建在早期经验基础之上，而像 tokio、hyper、regex 等老牌库，则经过多年生产考验，已变得异常健壮。
十年前，把 Rust 用于生产环境几乎意味着要不断造轮子、处理各种明雷和暗坑。虽然在一些领域（比如浏览器端 Rust）这依然如此，但对于通用系统和后端开发，这种时代已成过去。Rust 让我们能专注于业务逻辑，并产出极其高效和稳健的应用。
今天的 Rust 令人感受到"编程本该如此"
Rust 不只是一个"安全的选择"，它展现出了大型软件项目中前所未有的"程序员同理心"：构建过程简单稳健，拥有最棒的错误信息和 lint 报告、出色的文档和 IDE 集成、强大的 CI 和回归测试能力。Rust 更像一个程序员为程序员倾注热情的爱之项目。
十年前我们是否预见了这一切？我认为有些人确实看到了。当时的一些人深受现状所苦，但看到了这样一门语言、一个生态的潜力 ------ 由他们自己这样的人所设计。他们义务投入时间，造就了今天的 Rust。正如 Rust 的最初作者之一 Graydon Hoare 所说：
"Rust 今天的样子，是一群远见机构的大量投资，以及数千名相信长期回报的人共同努力的成果。"
十年前我选择把自己的时间和（以及投资人的）资金押注在 Rust 上，是因为我相信这种回报。我被社区热情感染，也被其潜力打动，更因为有众多聪明才智的人正在聚集。我非常高兴这些都不仅没有消退，反而日渐壮大，也感激所有为此贡献的人。
展望下一个十年，我期待什么？
更简单更快速的构建
随着工程与测试资源增长，我们将持续用更简单更快的实现，替代那些尽管成熟却复杂或缓慢的依赖。在链接、锁机制、回溯信息、平台优化例程、TLS、HTTP、git、压缩、构建工具链切换、构建自动化等方面，我都受益匪浅。接下来我尤其期待几个方向获得关注：
- 一个纯 Rust 实现、去除特殊行为的标准库
- 减少对系统链接器和 C 库的依赖
- 纯 Rust 实现的密码学库
- 更持久健壮的
BTreeMap - 以及一个 Rust 编写的游戏引擎（虽然我未必会用，但游戏开发者的性能优化手段常常让我惊艳）
近几个月我们公司 Tably 的编译时间提升了 60%，得益于 ThinLTO、前后端并行、增量编译、元数据流水线等底层优化。下一阶段可能带来突破的元改进包括：Rust 定制代码生成器、增量链接器、死代码清理、新求解器、cargo test 缓存等。
更好的可移植性、更少的 #[cfg()]
CI 中测试所有合法 #[cfg()]、目标平台和特性组合几乎不可能。这导致了未测试路径、潜在编译失败、文档缺失、IDE 支持受损、未使用导入警告等问题。
有 lint 被提议解决这个问题。一个更优的方向是将 #[cfg()] 移入 trait 系统中，如 where Platform: Unix 或 Platform: Avx2。这样编译器就能自动保证所有选项都能编译通过。再配合 specialization，即可优雅地实现不同平台特化版本的函数。元数据可在开发、测试、发布、不同特性组合和平台间共享，减少重复编译，加速 CI，也为 crates.io 的 MIR 缓存铺平道路。
一切皆可 const
常量求值可减少对宏和构建脚本的依赖，把运行时工作（甚至 panic）提前到编译时。当前仅支持很小一部分 Rust 代码（不支持 trait、不能分配内存），运行速度也慢得难以应对复杂场景。
假设可移植性足够，理论上所有代码都可在编译期执行。不可移植代码（如 FFI 或无备选的汇编）变得越来越少。过去已有多次尝试以 effect 系统扩展 const 支持，虽然反复被引入又撤回。我希望未来能避开额外语言复杂性，基于一个简单假设："一切都可在 const 上下文中执行"。虽然这需要攻克不少技术难题，但语言的简洁性值得为此努力。
更简单的并发模型
async 的复杂性成本较高，特别是 static 生命周期、取消安全性，以及与 trait 和 dyn 的兼容问题，目前都很难解决。此外，sync 与 async 原语之间的割裂，加之生态的不一致，也提高了 async 的"额外成本"。受 effect 启发的解决方案目前也不太靠谱。
Rust 1.0 前曾有 libgreen，通过用户空间协程实现并发，避免了 sync/async 的割裂，但代价是性能、可移植性和维护成本太高，最终被移除。现在资源充足，或许值得重拾这条路。我有一天可能会写个 PoC，基于 std::{fs, net} 包装构建一个零成本 fiber 协程模型，结合 fiber::{spawn, select} 和 generator!。
在更多领域脱颖而出
Rust 在浏览器端的应用仍未充分开发。我们经常遇到一些问题，说明当前认真用它做浏览器项目的人不多。比如避免未定义行为、在不同浏览器间获取堆栈追踪这些基本功能，我们也花了不少时间。我们当前这个站点使用的 leptos 框架已经走了很远（比我们之前用的 sycamore 更成熟），但依然存在不少边角问题。
某些领域，如快速原型和纯业务逻辑，可能永远不是 Rust 的强项 ------ 因为其设计初衷就是牺牲迭代速度换取其他优势。但大多数领域只是时间问题。图形界面、机器学习、游戏开发的门槛目前仍高，但那是由于已有生态的惯性、切换成本和文化惯性，并非不可克服。Rust 正稳步迈入这些领域，这要归功于持续不断的社区投入与创新。
总结
展望未来，Rust 的发展方向清晰而令人兴奋。随着采用者增多，开发与测试能力不断提升，反过来又吸引更多人加入，这一正向循环正加速进行。未来十年，我们将见证 Rust 更加精致、编译更快、覆盖更广领域，开发体验也将更加无缝。
在 Tably，我们会继续推动 Rust 的极限，亲历 ------ 并参与 ------ 它的下一个十年。
敬未来十年，继续下注 Rust！