所有代码都将收敛于 Rust

当时我在会议上发表演讲，为 Rust 在这些其他用例中的适用性做宣传时，我展示了下面这张图，来解释我们所认为的 Rust 相当独特的优势：

这张图展示了构建和演进一个系统随时间推移所需的投入。使用 Rust 时，初始投入（或者说曾经，我们后面会看到）比其他语言高得多：团队需要先学习所有权、借用和生命周期等概念——这些对大多数开发者来说完全陌生——才能让一个简单的程序通过编译。然而随着时间推移，投入会下降，最终会低于你在其他语言中通常看到的水准。

原因在于，在其他语言中，许多细小的细节和不变量并没有被显式地编码在代码库中，而只是隐含地存在于其中，因此团队必须依赖共享知识来使用代码库。代码库越大，这就越困难，而知识会随时间流逝而淡化，或者在人员离开时完全丢失。开发者最终在一个他们并不完全理解的系统中工作，对自己的改动没有信心，因此每次改动都需要更长时间才能做对，或者如果改错了，之后还要返工。Rust 通过其独特的机制在语言本身中编码了多得多的东西：所有权、生命周期、强制错误处理、强制穷尽匹配，以及其丰富的类型系统。编译器在一切运行之前就能捕获一大类错误，因此团队可以在多年之后、在最初编写代码的人早已离开之后，仍然有信心地修改 Rust 代码库。

基于这些考虑，我们专门向那些愿意做出额外前期投入、以换取卓越性能、可靠性和长期可维护性的团队推荐 Rust。像核心银行系统这样的金融应用就是最好的例子：当替代方案是一个把钱转到错误账户的 bug 时，没有人介意前期多花些时间。

anchor曲线已经改变

今天，你可能会说曲线看起来更像这样：

写代码的投入显然全面下降了，因为 LLM 能用任何语言写出不错的代码。编写（或生成）Rust 代码的初始投入可能仍然略高于其他技术，但差距已经远没有那么大。你仍然需要理解 Rust 的核心概念、生态系统、典型的开发基础设施等。然而，生成可运行的代码要容易得多。为了编译 Rust 代码而艰难地应付超长的泛型声明或借用检查器报错，已不再是曾经的瓶颈，因为编码智能体能把大部分工作做得很好。这让工程师们不必为了起步而翻越曾经巨大的初始障碍（当然，长期积累专业知识仍然不可妥协——详见下文）。

与此同时，没有改变的是最终系统的质量。用 Rust 构建的系统仍然会比用几乎任何其他技术栈实现的相同系统快得多、可靠得多、资源效率高得多。

这彻底改变了对是否基于 Rust 构建的评估。我在 2022 年常谈的那种权衡如今已不复存在。现在，与其他技术栈相比，你只需为 Rust 投入略高一点，却能获得显著更好的结果。这使得 Rust 成为许多用例的可行选择，而仅仅一年前，没人会考虑在这些场景中使用它。

anchor这已经在发生

我们已经在行业中看到了这种转变。与我们交流的越来越多团队将 Rust 用于后端，而以前他们可能会用 Rails、Django、Node.js 或 Java 来构建，或许底层还会用 Rust 编写性能关键的核心部分——如果真有的话。现在，他们用 Rust 构建整个系统。

像 OTTO 这样的公司——德国最大的电子商务公司之一，传统上是一家 Java 技术栈公司——正在非常成功地采用 Rust。GitHub 将 Copilot 代理运行时从 TypeScript 和 Node.js 迁移到了超过 80 万行 Rust 代码。OpenAI 用 Rust 重写了 Habitat——ChatGPT 背后基于 Python 的存储服务。甚至 DHH——Ruby on Rails 的创造者（当然是个有争议的人物，但他在科技界影响巨大，不容忽视）——现在也用 Rust 编写后端。

遗留代码库的迁移进一步推动了这一趋势。借助 LLM 和工具，直到最近还完全无法企及的遗留系统迁移项目如今已成为可能：那些因为重写需要数年时间和巨额成本而无人敢碰的老旧系统，现在可以以半自动化的方式、以极低的成本被替换（具体如何操作仍是一个活跃的研究和实验领域，但加速效果显然是真实的）。与此同时，这样做的压力也在增长。AI 模型在安全研究方面越来越擅长，包括发现和利用漏洞，这使得生产环境中的每一个内存不安全的代码库——尤其是暴露在互联网上的——都比以前成为更大的隐患。在几乎所有这类情况下，迁移的目标语言都将是 Rust。它是唯一一种主流语言，既能提供 C 和 C++ 的性能和底层控制能力，又具备内存安全性，并且能与现有 C 代码互操作，因此系统可以逐块迁移，而不必一次性大规模重写（请查看我们的C 到 Rust 迁移手册，了解如何将 C 代码库逐步迁移到 Rust 的指导）。

anchorRust 与 LLM 是完美搭配

Rust 不仅比以前更容易用 LLM 生成。对 LLM 来说，它可能也比大多数其他语言更高效。由于更多的约束被显式编码在 Rust 代码中，编译器开箱即用地为 LLM 提供快速而精确的反馈，甚至在任何额外的验证工具设置之前就已如此。一个编写 JavaScript 或 Ruby 的代理可能生成看起来没问题的代码，只在运行时或测试中（如果有测试的话）才失败。而一个编写 Rust 的代理在运行 cargo build 的那一刻就会了解到一系列错误，并能立即修复它们。

这也会影响你能对结果抱有多大信任。对于由 LLM 生成、我可能没有全面深入审查过的 Rust 代码，我会比同样系统用 JavaScript 写出来的版本更有信心。编译器已经运行了检查，并阻止了任何人类审查者都无法一致识别的问题。

anchor所有代码终将汇聚到 Rust

我们相信，所有这些最终会导致所有代码都汇聚到 Rust——不再只是高度关键的代码，而是任何代码。也有例外，比如在浏览器中运行、需要访问 Web 平台 API 的 Web 前端，它们仍然需要 JavaScript。对于几乎其他所有情况，用 Rust 以外的语言写代码几乎没有理由，因为任何其他语言都会给你更差的结果。

这笔账很好算：当替代方案的成本差不多，但其中一个能带来好得多的结果时，就没什么可犹豫的了。

anchor当心陷阱

然而，有一个陷阱正等着团队掉进去。仅靠 AI 从零开始用 Rust 生成一个应用是一回事。构建一个拥有真实用户的复杂系统，尤其是随着（不断变化的）团队长期维护和演进该系统，则完全是另一回事。后者需要工程基础设施，尤其是你所依托技术的组织级专业知识，才能让团队长期高效地处理系统。只依赖 AI 而不建立这些结构，是真实的风险。AI 让团队比以往任何时候都更快，但这对任何方向都成立：他们可以更快地构建出色的系统，也可以更快地陷入可怕的混乱，最终全速撞墙。

自 2022 年以来，我们一直在帮助团队采用 Rust，我们运营 EuroRust，还编写了 100 Exercises to Learn Rust 以及 C to Rust Migration Book。如果你有兴趣采用 Rust，并希望在此过程中获得指导，请联系我们！