由于我关于 Rust 的专业写作已经转移到了corrode 博客上，我可以在这里更随意一些，分享一下我对近期围绕在成熟软件中使用 Rust 的争论的一些个人看法。

所涉及的两个项目是 git（内核邮件列表讨论、Hacker News 讨论）以及最近用 Rust 重写的coreutils，后者将随 Ubuntu 25.10 Quizzical Quokka 一起发布。

促使我写这篇文章的是一场在 Twitter 上的讨论以及一篇题为“Are We Chasing Language Hype Over Solving Real Problems?”（《我们在追逐语言热度而非解决实际问题吗？》）的博客文章。

在这两种情况下，作者们都在揣测选择 Rust 背后的动机，而作为一名帮助团队在生产环境中使用 Rust 的人，我觉得这些观点……很可笑。

回想我创办 corrode 之初，人们总说 Rust 没有被用于任何严肃的项目。我通过客户工作了解到了一些生产环境的用例，但公开信息却很少。因此，我们开设了“Rust in Production”播客，以展示企业确实在为实际应用选择 Rust。然而，人们不喜欢被证明是错的，所以那种阴谋论现在已经演变成了“Big Rust”试图接管世界。😆

我们来看看博客文章和 Twitter 讨论串中提出的一些说法，看看这些说法其实很容易被驳斥。

“GNU Core Utils 在其整个存在期间基本上从未出现过任何重大安全漏洞”

要是真的如此就好了。一项快速 CVE 搜索显示，几十年来出现了多个安全问题，包括缓冲区溢出和路径遍历漏洞。就在几个月前，在sort中发现了一个堆缓冲区欠读漏洞，如果攻击者发送经过特殊构造的输入流，就会导致敏感数据泄露。

GNU coreutils 是全球使用最广泛的软件包之一，拥有数十亿次安装，有数百名（甚至数千名？）开发者审阅过代码。即便如此，漏洞依然会出现。不，编写正确、安全的 C 代码并不容易。不，即使你格外小心、格外自律也不行。

ls有五千行代码。（查看源代码）。仅仅为了打印文件名和元数据就有这么多代码，攻击面可不小！

“Rust 充其量只能匹敌 C 的性能，通常还要更慢”

Trifecta 的研究表明，在某些情况下编写比 C 更快的 Rust 代码是可能的。尤其是在并发工作负载以及需要内存安全保证的场景中。如果说编写安全的 C 代码已经很难，那就试试编写安全的并发 C 代码吧！

这正是 Rust 擅长的地方。你可以在无需担心安全问题的情况下实现惊人的并行化水平。而且，不，你不需要在代码中到处堆砌unsafe块。看看Steve Klabnik（史蒂夫·克拉布尼克）关于 Oxide 的最新演讲，他在演讲中展示了他们的引导程序和抢占式多任务操作系统 hubris——两者都是相当核心的系统代码——各自仅包含 5% 的unsafe代码。你完全可以用 Rust 编写完全不含 unsafe 代码的大型代码库。

举一个简单的例子，有一天我坐下来用 Rust 重写了cat。结果在我的机器上比 GNUcat快了 3 倍。你可以在这里阅读这篇文章。我所做的只是使用splice来复制数据，从而节省了一次内存复制。性能不仅取决于语言，还取决于你使用的算法和系统调用。

如果你能发挥 Rust 的优势，就能匹敌 C 的性能。至少不存在会阻碍这一点的技术限制。而且我个人更愿意在 Rust 中积极地优化代码，因为我不必担心会引入内存安全漏洞。感觉不止我一个人这么想。

“我们在行业中奖励新奇而非必要性”

这种说法忽略了大多数成功的公司（Google、Meta 等）主要使用经过实战检验的技术栈，而非最前沿的语言。这些公司拥有庞大的代码库，负担不起用最新流行的语言重写所有代码。但它们看到了在新组件中使用 Rust 并逐步重写现有组件的价值。这是因为70% 的安全漏洞是内存安全问题，而这些问题的修复成本极高。如果这些公司能够不切换到新语言就解决这些问题，它们肯定会这么做。

此外，Rust 早已不再算是新语言了。Rust 1.0 已是 10 多年前发布的！行业的发展虽然缓慢，但也没有那么慢。你可能会惊讶地发现，有多少老牌公司在使用 Rust，却甚至没有对外宣布，也不认为它是“新奇事物”。

“100% 是有策划的”

Twitter 讨论串中的多个人坚信这是某种协同的总体计划，而非开发者选择更好工具的结果，而 git 和 coreutils 的维护者们恰恰在公开论坛上开诚布公地讨论了他们的动机，供所有人查看。

“他们想取代/抹去 C。这不可能发生”

他们说得对。C 在短期内不会消失。野外有如此多的 C/C++ 代码，用 Rust 重写一切是不可行的。好消息是，你可以一次一个组件地增量式地用 Rust 重写 C/C++ 代码。这正是 git 维护者们计划要做的，即在新组件中使用 Rust。

“他们正在把采用 GNU 许可证的软件重写成采用 MIT 许可证的软件”

即使你使用 Rust，你仍然可以在 GPL 或任何你想要的其他许可证下授权你的代码。Git 本身仍然是 GPL，许多 Rust 项目使用各种许可证，而不仅仅是 MIT。对许可证的担忧往往是由不了解开源许可如何运作的人提出的，或者可能只是 FUD。

MIT 代码仍然与 GPL 代码兼容，你可以在同一个项目中毫无问题地同时使用它们。只是最终产品（即你交付给用户的东西，也就是二进制可执行文件）现在由于 GPL 的传染性而受到 GPL 的约束。

“这只是开发者感到无聊，想使用闪亮的新语言而已”

C 项目年长的维护者们正在退休，愿意为了在业余时间维护遗留代码而学习 C 的新开发者越来越少。C 开发者基本上正在逐渐消失。新开发者想使用现代语言，这又能怪谁呢？难道你想去维护一个有 40 年历史的 COBOL 代码库或一个古老的 Perl 脚本吗？我们必须向前看。

“为什么不完全构建一些全新的东西，而不是重写现有工具？”

事情没那么简单。代码只是故事的一部分。另一部分是生态系统、工具链、集成、文档和用户群。所有这些都需要数年时间来构建。用户不想改变他们的工作流程，所以他们想要即插即用的替代品。经过验证的接口和 API，无论多么粗糙和陈旧，都具有很大的价值。

但没错，新的工具也在用 Rust 构建。

“他们不知道如何真正解决问题，只会追逐潮流”

这简直是在无视那些多年来甚至几十年来一直在这些项目上工作、比任何人都更了解痛点的维护者的技术专长。

如果他们只是在追逐潮流，他们一开始就不会去维护这些项目！这些人是世界上最有经验的开发者之一，却还有人想教他们如何做自己的工作。

“这是感染软件的觉醒思想病毒的一部分”

想象一下，竟然有人认为内存安全是一场政治阴谋。显然，防止缓冲区溢出现在成了一种意识形态立场。与此最接近的是白宫的技术报告，该报告建议政府软件使用内存安全语言，并要求接受联邦资助的软件必须具备内存安全性，这是一个相当合理的观点。

结论

我还可以继续说下去，但我想你已经明白我的意思了。

给 Rust 一个公正机会的人都知道，它在内存安全、并发和可维护性方面具有优势。这不是追逐炒作，而是对软件质量的长期投资。随着越来越多的公司每天成功地采用 Rust，它正日益成为许多新项目的默认选择。

如果你有兴趣了解更多关于在生产环境中使用 Rust 的信息，请查看我的另一个博客或收听Rust in Production 播客。

哦，如果你认识发表此类观点的人，别再争论了，直接把这篇文章的链接发给他们吧。