世界怎么看 Rust——舆论的演变史
5.1 这是一部比技术本身更有趣的历史
一门编程语言的技术特性只是故事的一半，另一半是这门语言怎么在人心中建立地位。Rust在过去十年里经历了从"玩具项目"到"事实标准"的演变，这个过程充满了戏剧性，值得细细梳理。
我特别喜欢观察这种演变，因为它揭示的不只是Rust，而是整个技术社区是如何做集体决策的——哪些因素真正影响了工程师的选择，哪些是媒体炒作，哪些是真正的技术判断。
5.2 2010–2015年：从实验室到1.0
5.2.1 Mozilla的内部项目
Rust的起源可以追溯到2006年，Mozilla员工Graydon Hoare的个人项目。2009年Mozilla正式赞助，目标是为Firefox的渲染引擎Servo提供一门更安全的语言。
这个阶段的Rust和后来的Rust差别极大。语言设计在快速迭代，很多特性加了又删，所有权系统的形态也和最终版本不同。早期的Rust有垃圾回收、有goroutine风格的任务系统，很多现在觉得理所当然的特性那时候都不存在。
这不是贬义——这是正常的研究性语言开发。但这也意味着在这个阶段，关注Rust需要很高的风险承受能力，你写的代码可能下一个版本就无法编译了。
5.2.2 2015年：1.0发布，承诺稳定性
2015年5月，Rust 1.0正式发布。这是一个里程碑，不是因为Rust语言在那一刻突然变好了，而是因为Rust团队做出了一个重要承诺：向后兼容性。从1.0开始，能在Rust 1.0上编译的代码，在后续版本上也应当能编译（除非你用了被显式标记为不稳定的特性）。
这个承诺对于生产级使用至关重要。没有人愿意在一门每隔几个月就破坏性更新的语言上建设关键基础设施。
1.0发布的时候，反应很平淡。技术媒体报了一下，Hacker News上有一些讨论，然后就过去了。没有人知道未来它会受到这么大的关注。
5.3 2016–2019年：小圈子狂热
5.3.1 "最受喜爱语言"的连续登顶
Stack Overflow每年做开发者调查，其中有一项是"最受喜爱的语言"（Most Loved Language）——注意，不是"用得最多"，而是"用过之后最喜欢"。
Rust从2016年开始连续霸榜。这个数据本身需要谨慎解读：喜爱度高不代表使用率高，早期喜欢Rust的人大多是那些专门去探索这门语言的技术狂热分子，样本有偏差。
但这个数据也揭示了一件事：用过Rust的人，大多数都很喜欢它。这种口碑在技术社区里是稀缺的——大多数语言用过之后要么中性要么有人爱有人恨，Rust的喜爱率异常地高。
5.3.2 Rustacean文化的形成
这个阶段，Rust社区形成了一种独特的文化——Rustacean（Rust用户自称，取螃蟹形象，因为Rust的吉祥物是一只螃蟹）。这个群体的特点是：技术上非常认真、讨论质量高、对语言设计有浓厚兴趣、彼此之间有一种"我们在做一件重要的事"的使命感。
Rust社区的行为准则（Code of Conduct）写得很详细，明确要求包容和友好，这和某些技术社区的"精英主义"文化形成对比。Rust的文档质量也在这个阶段建立了口碑——《Rust程序设计语言》（也叫"The Book"）被公认为开源项目文档的标杆。
5.3.3 第一批重量级采用者
npm：2019年，npm（Node.js的包管理器注册中心）宣布用Rust重写了CPU密集型的部分。具体来说是@npmcli/arborist的一部分逻辑。这是一个信号——工业界开始在真实的、影响数百万开发者的系统里用Rust。
Dropbox：Dropbox用Rust重写了其存储后端的核心同步引擎。原先是Python实现，面对海量文件同步时性能瓶颈明显。Rust实现在性能和内存使用上都有显著提升。
Discord：Discord在2020年发布了一篇著名的博客文章《Why Discord is switching from Go to Rust》，讲述了他们把处理消息读取状态的服务从Go换成Rust的经历。Go版本有定期的延迟峰值，因为GC在清理时会暂停。Rust版本没有GC，延迟更稳定，内存使用也更低。这篇文章在技术圈广泛传播，让很多人第一次认真考虑Rust。
5.4 2020年：Linux内核里的那场争论
5.4.1 "Rust进Linux内核"的提案
2020年，一个名叫Nick Desaulniers的谷歌工程师在Linux内核邮件列表上提出了将Rust作为Linux内核的第二语言的想法。Linux内核几十年来只用C（和少量汇编），引入任何第二语言都是极其敏感的决定。
这件事在Linux社区引发了激烈争论。
5.4.2 反对的声音
反对意见是有道理的，不是保守主义情绪：
学习成本：Linux内核有数千名贡献者，让所有人都学Rust是不现实的。Rust的学习曲线远比C陡峭，尤其是对习惯了C风格的内核开发者。
工具链稳定性：C的工具链（GCC）极其成熟，Rust的工具链（rustc/LLVM）相对年轻。内核对工具链的稳定性要求极高。
FFI边界的安全性：Rust和C代码的互操作需要unsafe块，边界处的安全性保证比纯Rust代码弱。如果大量代码在Rust和C之间互调，安全收益可能不如预期。
维护责任：谁来维护内核里的Rust代码？如果原作者离开了，能找到足够多的懂Rust的内核开发者接手吗？
5.4.3 Linus的态度转变
Linus Torvalds的态度很有意思。他早期对Rust进内核持保留态度，但不是极端反对。他的原话大意是：如果Rust真的能解决实际问题，我愿意看，但要证明这一点，不能只是口头上说"Rust更安全"。
经过两年的讨论和实验，Linux 6.1（2022年12月发布）正式把Rust支持合并进主线。这不是说内核代码都改成Rust了，而是内核构建系统开始支持编译Rust代码，为未来的Rust驱动和内核模块提供基础。Linus在采访中说，他个人不会写Rust，但他看到了它的价值。
这件事的象征意义远大于实际影响。Linux内核接受Rust，等于是世界上最保守的大型C项目给Rust盖了章，这对整个行业的信号是：Rust不是玩具，是可以用于极端严肃场景的语言。
5.5 2022年：巨头集体站台
5.5.1 微软
2022年，微软在多个公开场合表态支持Rust。微软安全响应中心（MSRC）的工程师发表文章，指出Windows历史上70%的安全漏洞是内存安全问题，而Rust是解决这个问题的有力工具。
微软不只是嘴上说说。他们开始把Windows的部分组件用Rust重写，包括一些字体处理代码、部分网络栈组件，以及最值得关注的：Windows驱动开发框架开始提供Rust支持。微软还雇佣了多位Rust核心开发者，对Rust工具链本身进行贡献。
5.5.2 Google
Google是Rust进Android的主要推动者。Google安全博客的数据显示：在Android里，C/C++代码的内存安全漏洞发现率远高于Rust代码。2021年开始，Android新增的native代码越来越多用Rust写。到2023年，Android里大约有150万行Rust代码。
Google还在Chromium（Chrome的开源基础）里开始引入Rust，并为Rust工具链（特别是编译速度的改进）贡献了大量工程投入。
5.5.3 NSA
美国国家安全局（NSA）在2022年发布了一份技术报告，明确推荐使用内存安全语言，Rust被列为推荐选项之一。这份报告的受众是美国政府和军事机构的IT部门，代表着"安全机构的官方背书"，在保守的政府IT采购圈里有一定影响力。
这个画面有点魔幻：一家浏览器公司（Mozilla）发明的语言，被国家安全局推荐给政府机构使用。
5.5.4 AWS、Meta、Cloudflare
AWS（亚马逊云服务）长期是Rust的大用户，Firecracker（用于Lambda和Fargate的轻量级虚拟化层）就是Rust写的。Meta在其内部基础设施里大量使用Rust，并对rustfmt（Rust代码格式化工具）等工具链项目有贡献。Cloudflare用Rust重写了Pingora（一个HTTP代理库，替代NGINX在Cloudflare内部的使用），并把它开源。
这些公司的共同点是：超大规模、对性能和可靠性极度敏感。他们不是因为Rust"时髦"而选它，是因为在他们的规模下，内存安全问题和性能问题的代价是以亿美元计的。
5.6 2023–2026年：从"值得尝试"到部分领域的事实标准
5.6.1 白宫的报告
2024年2月，美国白宫国家网络主任办公室（ONCD）发布了一份报告，题为《Back to the Building Blocks: A Path Toward Secure and Measurable Software》，明确呼吁开发者转向内存安全语言，并点名Rust。
政府报告通常是行业趋势的滞后指标而不是先行指标，但这份报告的意义在于它正式把"内存安全"提升到了国家安全的层面，这对政府采购合同、安全法规、行业标准都会产生实际影响。
5.6.2 Stack Overflow调查：数据的意义
Stack Overflow的"最受喜爱语言"调查，Rust从2016年到2023年连续八年第一。2024年调查改了问法，用"Admired"替代"Loved"，Rust依然排名第一，以80%的比例遥遥领先。
这个数据的意义在2024-2025年已经有了变化：使用Rust的人越来越多，样本不再只是狂热爱好者。2023年Stack Overflow调查里，Rust用户里有约13%是"在工作中大量使用"，相比2019年的约5%已经提升很多，但相比Python（约49%）还有很大差距。喜爱度高、使用率相对低，这个格局在2026年仍然存在，但差距在缩小。
5.6.3 "重写成Rust"成为一种文化现象
"Rewrite it in Rust"（缩写RIIR，有时候也被自嘲为一种宗教狂热）成为了技术社区的梗。每当一个性能不好的工具被提起，就有人说"该用Rust重写了"。
这个梗很有意思，因为它承载了真实的工程判断和轻度的自嘲。确实有很多工具重写成Rust之后效果很好（前面列的那些CLI工具），也确实有人把"Rust"当成了银弹而不是工具。
5.6.4 培训和招聘市场的变化
到2025-2026年，Rust开发者的薪资在各平台的统计里持续偏高，供需缺口明显——会Rust的工程师少，需要Rust的岗位在增长。这是一个经典的新兴技术扩散现象：早期采用者获得溢价，随着人才供给增加，溢价会逐渐收窄。
大学课程开始出现Rust，一些计算机系把原来的系统编程课（用C/C++）改成用Rust教，理由是"相同的概念，更好的即时反馈"——借用检查器给出的错误信息帮助学生理解内存管理，比C的"运行崩溃了但你不知道为什么"更有教育价值。
5.7 "最受喜爱"背后的深层逻辑
5.7.1 为什么工程师喜欢Rust
喜欢Rust的工程师通常能说出几个具体原因，不是"感觉好"，是真实的体验：
"编译通过就基本对了"。这句话出现在大量Rust用户的回忆里。Rust的类型系统和借用检查器极其严格，如果你的代码能编译，它通常能正确运行，没有意外的空指针，没有数据竞争，没有内存泄漏。这种感觉和Python、JS的开发体验截然不同——后者是"先跑起来，运行时再发现问题"。
错误信息是顶级的。Rust的编译器错误信息在所有主流语言里是最友好的，没有之一。它不只是告诉你"这里有错误"，它会解释为什么错、可能的原因是什么、应该怎么修。很多人第一次用Rust时被这个惊到，因为他们太习惯C++那种令人绝望的模板错误信息了。
工具链集成度高。cargo（Rust的包管理器和构建工具）把依赖管理、编译、测试、文档生成、发布到crates.io全部集成在一个工具里，而且这些功能开箱即用，不需要配置。相比Python的pip+venv+setup.py+poetry+...的碎片化状态，cargo的体验不知道好多少。
5.7.2 为什么不喜欢Rust的人不喜欢
学习曲线。所有权系统对新手是真实的障碍。"跟借用检查器搏斗"是一种普遍的初学体验，有些人度过了，有些人在这里放弃了。
开发速度。在Rust里做一件事通常比Python慢3-5倍（开发时间，不是运行时间）。如果项目对开发速度的要求高于对运行速度的要求，这是一个真实的劣势。
Rust社区的布道文化。有些Rust用户有点……过分热情，每当有人说"我在用Python"，就会有人跳出来说"为什么不用Rust？"。这种文化让一部分人对Rust产生了本能的抵触。Rust核心团队意识到了这个问题，在文档和社区指南里明确提到Rust不是所有问题的解决方案。