2006年的一天,Graydon Hoare回到公寓,发现电梯又坏了。他住在21楼。
爬楼梯的时候,这位Mozilla的程序员越想越气。“我们这些搞计算机的,连个电梯软件都写不好?“他后来回忆道,“这太荒谬了。”
电梯软件为什么会崩溃?答案藏在内存里。这些嵌入式系统通常用C或C++编写,这两种语言赋予程序员对内存的绝对控制权——这种控制权是一把双刃剑。当程序忘记释放内存、或者访问了已经释放的内存区域,崩溃就来了。更糟糕的是,这类错误往往不会立即暴露,而是像一个定时炸弹,在最不合适的时候引爆。
Hoare那天回家后打开笔记本电脑,开始设计一门新的编程语言。他给它起名叫Rust——取自一类以"过度工程化的生存能力"著称的真菌。
十七年后,Rust成为Linux内核的官方支持语言。2025年12月,在年度内核维护者峰会上,Linus Torvalds和其他核心开发者正式决定:Rust不再是实验性功能,而是与C并列的核心开发语言。
一门2015年才发布1.0的语言,如何说服运行着全球数十亿设备的操作系统接受它?答案藏在两个数字里。
70%的问题
2019年,微软安全响应中心发布了一份报告:从2006年到2018年,微软产品中发现的安全漏洞中,约70%源于内存安全问题。
这不是微软独有的困境。Google的Chrome团队给出的数字几乎相同:约70%的严重安全漏洞与内存安全相关。这些漏洞有一个共同的名字:缓冲区溢出、使用后释放(use-after-free)、双重释放、空指针解引用……
它们听起来像是教科书上的概念,但后果是真实的。2014年的Heartbleed漏洞让攻击者可以从服务器内存中读取敏感信息,影响了全球数百万网站。这类漏洞的根源,都是程序对内存的不当操作。
C和C++的问题在于它们假设程序员永远不会犯错。如果你写:
char* ptr = malloc(100);
// ... 一些代码 ...
free(ptr);
// ... 更多代码 ...
ptr[0] = 'a'; // 使用已经释放的内存
编译器会毫无怨言地接受这段代码。运行时,它会访问一块可能已被其他数据占用的内存——可能崩溃,可能静默地破坏数据,也可能被攻击者利用来执行任意代码。
为什么不用其他语言?
Java、Python、Go这些语言有垃圾回收机制(Garbage Collector),会自动管理内存,程序员不需要手动分配和释放。但垃圾回收是有代价的:
- 性能开销:垃圾回收器需要定期暂停程序执行,扫描内存。对于响应时间要求严格的系统,这种停顿是不可接受的。
- 内存占用:垃圾回收语言通常需要更多的内存来工作。云服务提供商Amazon Web Services发现,Rust代码运行时的电力消耗只有Java代码的一半——这意味着同样的数据中心可以承载两倍的工作负载。
- 不可预测性:垃圾回收的触发时机不受程序员控制,这在实时系统中是一个严重问题。
系统编程——操作系统内核、数据库引擎、浏览器渲染引擎——需要C和C++级别的控制力。但传统上,这种控制力伴随着内存安全的风险。
Rust试图回答一个问题:能否在不牺牲控制力的前提下,消除内存安全问题?
所有权:一个反直觉的设计
Rust的解决方案叫做"所有权系统”(Ownership System)。它的核心思想可以概括为三条规则:
- 每一块数据都有且只有一个"所有者”(owner)
- 当所有者离开作用域,数据会被自动释放
- 数据可以被"借用"(borrow),但借用的规则极其严格
这些规则听起来简单,但它们的组合产生了深远的影响。
移动语义
在C++中,这段代码是完全合法的:
std::string a = "hello";
std::string b = a; // a和b都指向同一块内存
// 程序结束时,两者的析构函数都会被调用
// 可能导致双重释放
Rust采用了不同的语义:
let a = String::from("hello");
let b = a; // 所有权从a转移到b
// 此时a已经无效,任何对a的使用都会导致编译错误
当所有权转移后,原来的变量就"死亡"了。编译器会在编译时检查这一点,拒绝任何使用已失效变量的尝试。
借用规则
更精妙的是借用规则。Rust允许你创建数据的引用(借用),但有两条铁律:
- 要么有一个可变引用,要么有任意数量的不可变引用,但不能同时存在
- 引用必须始终有效(不能指向已经释放的内存)
let mut s = String::from("hello");
let r1 = &s; // 不可变借用
let r2 = &s; // 再来一个不可变借用,没问题
let r3 = &mut s; // 编译错误!已有不可变借用时不能可变借用
这条规则消除了一个在并发编程中臭名昭著的问题:数据竞争(data race)。当两个线程同时访问同一块内存,且至少有一个在写入,就可能出现数据竞争。Rust的借用规则在编译时就阻止了这种情况。
借用检查器
这些规则的执行者叫做"借用检查器"(borrow checker)。它在编译阶段分析代码的控制流,追踪每个引用的生命周期。
早期版本的Rust使用"词法作用域生命周期"——引用的有效期由它在代码中的位置决定。这导致了一些令人沮丧的情况:明明代码逻辑上没问题,但借用检查器就是不通过。
2018年,Rust引入了"非词法生命周期"(Non-Lexical Lifetimes, NLL)。借用检查器开始基于实际的控制流图进行分析,而不仅仅是代码的词法结构。一个引用只要在最后一次使用之后就不再被视为"存活",即使它所在的作用域还没结束。
这个改进让Rust变得更易用,同时保持了安全保证。
1000倍的差距
2025年11月,Google安全博客发布了一组令人瞩目的数据。
Android操作系统的内存安全漏洞数量,从2019年的223个,下降到2024年的不到50个。这是该平台历史上第一次,内存安全漏洞占总漏洞的比例降至20%以下。
更令人惊讶的是漏洞密度的对比。Android团队统计:
- C/C++代码:约每100万行代码产生1000个内存安全漏洞
- Rust代码:500万行代码中仅发现1个潜在的内存安全漏洞,密度约为每100万行0.2个
1000倍的差距。
这不是魔法。Android团队发现,Rust代码的回滚率(因严重问题被撤回的比例)比C++低4倍,代码审查时间少25%。更安全的代码,同时也是更高效的代码——这颠覆了"安全需要牺牲效率"的传统观念。
unsafe的边界
Rust并非万能。约19%的crate使用了unsafe关键字——这是一个显式声明,告诉编译器"我知道我在做什么,请暂时关闭安全检查"。
unsafe块内可以执行原始指针操作、调用C函数、访问可变静态变量。这些操作是必要的——操作系统内核需要与硬件交互,需要调用现有的C库。
但unsafe不是放弃安全。Rust社区发展出了一套"安全封装"的实践:将unsafe代码隔离在最小范围内,用安全的API封装它们,并在代码注释中详细说明安全保证的理由。
Google的数据显示,即使是unsafe Rust代码,其漏洞密度也远低于等量的C/C++代码。原因可能在于:使用unsafe是一种显式的、有意识的行为,程序员在写这些代码时会格外小心;同时,Rust的工具链(如Miri解释器)可以帮助验证unsafe代码的正确性。
Linux内核的接纳
将Rust引入Linux内核的旅程始于2020年,但真正的里程碑在2022年。
当年10月,Linus Torvalds本人批准了一个pull request,将Rust支持合并到Linux 6.1。这是Linux内核30多年历史上,第一次接受除C和汇编之外的语言作为一级公民。
Torvalds的态度经历了明显的转变。2020年,他在开源峰会上表示Rust"可能会进入内核"。2022年,他说"除非发生意外,Rust会在6.1中"。到了2024年,他在接受采访时说:“如果有维护者反对Rust,我会介入。”
但这个过程并不顺利。
文化和技术的碰撞
2024年8月,Rust for Linux项目的核心维护者之一Wedson Almeida Filho宣布退出。他在给内核邮件列表的信中写道,自己"厌倦了处理非技术性的胡扯"。
争议的核心在于:Linux内核有着庞大的C代码库和深厚的C文化。一些维护者对Rust持怀疑态度,认为它会增加复杂性、分裂社区。有人质疑Rust的编译器稳定性——内核需要支持多种架构和编译器版本,而Rust目前依赖一些不稳定特性。
另一方面的担忧是生态系统:C有着40多年的工具链积累,Rust在这方面还有差距。调试、性能分析、静态分析工具都需要时间成熟。
Torvalds本人试图平衡这些声音。他在2024年的内核维护者峰会上表示,理解老一辈C程序员的顾虑,但强调Rust的价值已被证明。“我们不会一夜之间重写内核,“他说,“但新的代码应该考虑使用Rust。”
驱动的现实
尽管争议,Rust已经在Linux内核中找到了位置。截至2024年底:
rnull:一个null设备的替代实现- ASIX AX88772A和Realtek网络PHY驱动
- Android Binder IPC驱动
- 只读ext2文件系统
- Nova项目:计划用Rust重写NVIDIA开源驱动
正在开发中的还有:QR码恐慌处理器、NVMe驱动、Asahi Linux的Apple GPU驱动。
这些项目有一个共同点:它们是相对独立的模块,有清晰的边界,适合用Rust进行实验。内核社区采取了渐进策略——不是重写现有代码,而是在新代码中验证Rust的价值。
政府的背书
2024年2月,美国白宫科技政策办公室发布了一份技术报告,标题是《回归基石:迈向内存安全的未来》。
报告开门见山:内存安全漏洞是"最普遍的已披露软件漏洞类型”。报告列举了符合内存安全标准的语言:Python、Java、C#、Go、Swift、Rust……
这是美国政府第一次正式建议软件开发者放弃C和C++。
同年,NSA和CISA联合发布了网络安全信息表,详细分析了内存安全语言的采用策略。报告指出,在浏览器和内核中,约60-70%的漏洞源于内存安全问题。
这些政府报告不是无的放矢。它们反映了一个共识:在关键基础设施领域,内存安全漏洞已经从"技术问题"上升为"国家安全问题”。
安全关键系统的门槛
汽车、航空、医疗设备——这些领域有着严格的安全标准。ISO 26262(汽车)、IEC 61508(工业控制)、IEC 62304(医疗设备)定义了不同级别的安全完整性等级。
Rust正在进入这些领域。Ferrous Systems公司开发了Ferrocene,一个符合ISO 26262标准的Rust工具链,使Rust可以用于认证的安全关键应用。欧洲航天局(ESA)已经开始评估Rust在航天系统中的应用。
2026年1月,Rust官方博客发表文章《在安全关键领域发布Rust需要什么》,详细讨论了各行业标准对编程语言的要求。文章指出,Rust的类型系统和所有权模型天然符合安全关键系统的许多要求。
不是没有代价
如果Rust如此完美,为什么不是所有人都在用它?
学习曲线
Rust的学习曲线是真实的。2024年的Rust社区调查显示,31%的受访者认为"认知难度"是不使用Rust的主要原因。
所有权和借用需要一种不同的思维方式。在C++中,你可以在任何时候访问任何指针(如果它还活着);在Rust中,编译器会强迫你思考数据的生命周期。这种思考是额外的认知负担,但也是安全的来源。
一个常见的抱怨是"与借用检查器搏斗"——代码逻辑上是对的,但编译器就是不让过。有经验的Rust开发者说,这种感觉会随着时间消失,取而代之的是对"内存布局"的直觉把握。
编译时间
Rust的编译速度是另一个痛点。严格的编译时检查意味着编译器要做更多工作。大型Rust项目的编译时间可能比等量的C++代码更长。
社区正在努力改进这个问题。并行前端编译、增量编译、更快的链接器——这些优化正在逐步推进。但编译速度仍然是被调查者最常提到的生产力障碍。
生态系统
C和C++有着40多年的生态系统积累。你需要的功能,几乎都能找到成熟的库。Rust的crates.io已经有超过14万个包,但覆盖面和成熟度仍有差距。
特别是嵌入式系统和特定硬件领域,C的统治地位仍然稳固。Rust正在追赶,但改变需要时间。
两种哲学的对峙
Rust的成功引发了一个更深层的问题:为什么不是让C++变得更安全?
这实际上正在发生。C++社区正在推动"安全特性"的添加,如边界检查、生命周期分析工具。Clang编译器已经实现了类似Rust的生命周期注解实验性支持。
但Rust支持者认为,这不够。安全必须是默认的,而不是可选的附加组件。一个程序员可以在90%的代码中小心翼翼,但那10%的疏忽就可能导致灾难。
C++的历史包袱太重。它不能破坏数以亿计的现有代码。任何安全改进都必须是向后兼容的,这限制了激进变革的可能性。
Rust没有这个包袱。它从零开始设计,让安全成为第一性原理。这是一种哲学选择:强迫程序员在编译时正确,而不是在运行时崩溃。
还在继续的故事
2025年12月,Linux内核维护者峰会做出了历史性的决定:Rust正式成为内核的核心语言,不再被标记为"实验性"。
这个决定的象征意义大于实际影响——实际工作中,Rust代码在内核中的占比仍然很小。但它传递了一个信号:Linux社区认为Rust是未来的一部分。
同月,微软宣布计划在2030年前用Rust重写Windows内核和Azure基础设施的关键组件。Android平台上的Rust代码量已经与C++相当。Dropbox用Rust重写了同步引擎,Discord用Rust替换了Go代码后性能提升10倍。
Rust用户数量从2022年的200万增长到2024年的400万。在Stack Overflow的开发者调查中,Rust连续七年被评为"最受喜爱的编程语言"。
但这些数字背后,是更深层的趋势:行业正在重新评估"效率"的定义。
过去,效率意味着执行速度和内存占用。今天,效率还包括开发效率、安全效率、维护效率。Rust在第一项上与C++相当,在后三项上展现出优势。
这不是说Rust会取代C++。数以亿计的C++代码将继续运行数十年。但新的系统代码,尤其是在安全敏感领域,会越来越多地使用内存安全的语言。
回到那个21楼的电梯。Graydon Hoare在2006年爬楼梯时的愤怒,催生了一门改变编程世界格局的语言。他后来淡出了Rust项目,把接力棒交给了社区。
2015年Rust 1.0发布时,他在邮件列表里写了一句话:“大多数编程语言,都默默死在角落里。”
Rust没有。它用十七年的时间,从一个人的愤怒,走到了操作系统内核的中心。
参考资料
- Microsoft Security Response Center. “A Proactive Approach to More Secure Code.” 2019.
- Google Security Blog. “Rust in Android: move fast and fix things.” November 2025.
- The Rust Foundation. “Unsafe Rust in the Wild: Notes on the Current State of Unsafe Rust.” May 2024.
- Wikipedia. “Rust for Linux.” Accessed 2024.
- MIT Technology Review. “How Rust went from a side project to the world’s most-loved language.” February 2023.
- The Register. “Rust for Linux maintainer steps down in frustration.” September 2024.
- White House Office of the National Cyber Director. “Back to the Building Blocks: A Path Toward Secure and Trustworthy Software.” February 2024.
- NSA & CISA. “Software Memory Safety.” November 2022.
- Rust Blog. “2024 State of Rust Survey Results.” February 2025.
- Rust Blog. “What does it take to ship Rust in safety-critical?” January 2026.
- Phoronix. “Linux Kernel Highlights For 2025: Schedulers, Rust & Torvalds.” December 2025.
- Ars Technica. “As the Kernel Turns: Rust in Linux saga reaches the ‘Linus in all his glory’ stage.” February 2025.