由于我关于 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 的研究表明，在某些情况下用 Rust 编写的代码完全可以比 C 更快，尤其是在并发负载下还能保证内存安全的情况下。如果说写出安全的 C 代码已经很难，那就试试写出安全的并发 C 代码吧！

这正是 Rust 的闪光点。你可以在无需担心安全问题的前提下实现极高程度的并行化。而且，你根本不需要把代码里塞满 unsafe 块。看看Steve Klabnik 最近关于 Oxide 的演讲就知道了，他在演讲中展示了他们的引导程序和抢占式多任务操作系统 hubris——两者都是非常底层的系统代码——各自的 unsafe 代码都只占 5%。用 Rust 完全可以写出完全不含 unsafe 的大型代码库。

举个简单的例子，有一天我动手用 Rust 重写了 cat，结果在我的机器上比 GNU cat 快了 3 倍。你可以在这篇文章中看到详细介绍。我所做的不过是用 splice 来拷贝数据，从而省掉了一次内存拷贝。性能不仅仅取决于语言，还取决于你使用的算法和系统调用。

如果你能发挥 Rust 的长处，就能达到 C 的性能。至少在技术上并没有什么障碍会阻止你做到这一点。就我个人而言，在 Rust 中我更愿意大胆地做激进优化，因为不用担心会引入内存安全漏洞。看起来有这种感觉的不止我一个。

“行业里我们奖励的是新奇，而不是必要性”

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

再说，Rust 也早就不算什么新语言了。Rust 1.0 已经发布了十多年！行业的发展虽然缓慢，但也没慢到那个地步。你可能会惊讶地发现，有多少成熟的公司已经在用 Rust，却从未对外宣扬，也根本不把它当成什么“新奇玩意儿”。

“百分之百是有组织的策划”

在那条 Twitter 讨论串里，好几个人都坚信这是某种协同一致的宏大计划，而不是开发者在选择更好的工具，然而 git 和 coreutils 的维护者们早已在公开论坛上坦诚地讨论过自己的动机，所有人都能看到。

“他们想取代/消灭 C，这不可能发生”

在这点上他们说得没错。C 在短期内不会消失。现实世界中存在着海量的 C/C++ 代码，把所有东西都用 Rust 重写根本不现实。好消息是，你可以一点一点地用 Rust 增量重写 C/C++ 代码，一次重写一个组件。git 的维护者们正是这么打算的——在新组件中使用 Rust。

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

即使你使用 Rust，也可以照样把代码以 GPL 或任何你想要的许可证发布。Git 本身仍然是 GPL，许多 Rust 项目也使用各种不同的许可证，并不只有 MIT。所谓许可证的担忧，往往是那些不了解开源许可如何运作的人提出来的，也可能纯粹是危言耸听。

MIT 代码与 GPL 代码仍然是兼容的，你完全可以在同一个项目中同时使用两者而不会有问题。只不过最终交付给用户的产物（也就是二进制可执行文件）会因为 GPL 的传染性而被 GPL 所覆盖。

“不过是开发者闲得无聊，想玩些炫酷的新语言罢了”

C 项目年迈的维护者们正在退休，愿意为了在业余时间维护遗留代码而去学 C 的新开发者越来越少。C 开发者实质上正在走向消亡。新一代开发者想用现代语言工作，这又有什么可指责的呢？难道你愿意去维护一个有 40 年历史的 COBOL 代码库或陈旧的 Perl 脚本吗？时代总得向前。

“为什么不去做个全新的东西，非要重写现有工具？”

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

当然，用 Rust 构建的全新工具也确实在不断涌现。

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

这完全是在无视那些在这些项目上耕耘了数年乃至数十年的维护者的专业水平，而他们比任何人都更清楚其中的痛点。

如果他们真的只是在追逐潮流，压根就不会来维护这些项目！这些人是世界上最有经验的开发者之一，却还有人想教他们该怎么工作。

“这是感染软件界的‘觉醒病毒’的一部分”

居然会有人把内存安全当成政治阴谋。看来防止缓冲区溢出如今也成了一种意识形态立场。与此最接近的大概就是白宫的那份技术报告了，报告建议政府软件使用内存安全语言，并要求接受联邦资助的软件必须具备内存安全性——这其实是相当合理的观点。

结论

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

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

如果你想进一步了解在生产环境中使用 Rust，可以看看我的另一个博客，或收听《Rust in Production》播客。

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