我第一次对 Rust 产生敬意，不是因为基准测试，而是因为恐惧。

我曾排查过一个线上问题：代码看起来很干净，日志看起来很正常，但总觉得哪里不对劲。没有戏剧性的报错，没人写出明显糟糕的代码，系统也没有尖叫。

它在低语。

一个对象存活的时间比它应有的更长。一条清理路径的表现与我们的设想不同。一个边缘情况漏网了，因为每个人都觉得这段代码“显而易见”。

这个词很危险：显而易见。

许多崩溃的系统，曾经都让人觉得“显而易见”没问题。那一天改变了我对软件安全的看法。我不再相信仅靠“细心的开发者”就足够了。细心的开发者当然有帮助，严格的代码审查有帮助，完善的测试也有帮助。但当系统变得足够庞大时，单靠人类的自律，就像用一面脆弱的墙去抵御汹涌的河流。

这也是为什么 Rust 进入 Linux 不仅仅是一个编程语言的故事。它不是 Rust 粉丝赢得了一场辩论，也不是 C 开发者失去了地位，更不是为了装作严肃的跟风。

这是一个关于生存的故事。

Linux 运行在手机、服务器、路由器、云主机、Android 设备、汽车、嵌入式主板、容器以及我们接触到的几乎所有核心基础设施之下。当 Linux 变得更安全时，世界也会在不知不觉中变得更安全。

这正是关键所在。优秀的基础设施不需要掌声，它只需要更少地发生故障。

Rust For Linux 不再是讨喜的实验。它正成为内核的安全层。不是整个内核，不是新的王者，也不是 C 的替代品。

只是一个安全层。

但这可能比重写整个内核更重要。

多年来，Rust 在 Linux 中的存在感就像个支线剧情。人们谈论它、争论它、庆祝它，也嘲笑它。

但内核不在乎炒作。

Linux 不会因为开发者在网上激动就采纳某个想法。只有当这些想法经受住了维护者的审视、代码审查、回归测试、构建规则、硬件问题以及漫长的技术争论后，它才会被接受。

这就是为什么此刻的感觉与众不同。Rust 不再只是站在内核边缘观望。它拥有了真正的内核文档、真正的抽象层、真正的驱动程序、真正的子系统讨论，以及真正的证据，证明这个想法正在从理论走向生产级工程。

过去的头条很简单：“Rust 要来了。”

现在更好的头条是：“Rust 正在 Linux 最危险的边缘接受测试。”

这个区别至关重要。因为目标不是让 Linux 变得时髦，而是让某些类别的内核错误在书写时本身就变得更难产生。

这是很多人忽略的一点。Rust 进入 Linux 不是因为开发者对 C 感到厌倦，而是因为“小心点就好”这种说法是有极限的。而内核恰恰生活在这些极限最伤人的地方。

最有力的证明不是一场会议演讲。最有力的证明往往很无聊：驱动程序、抽象层、构建支持、子系统实验、内核文档，以及真正的维护者在审查真正的代码。

严肃的基础设施就是这样变革的。Rust 正在出现在 ASIX PHY、Android Binder、Nova GPU、Tyr GPU、Null Block 和 DRM Panic 等工作中。这些可不是为了给 Rust 贴金而随便捏造的玩具示例。

它们恰恰是内核中那些涉及内存、状态、硬件、失败路径和 unsafe 边界，并且会迅速变得极其危险的区域。这很重要。

PHY 驱动贴近硬件；Binder 在 Android 通信中至关重要；GPU 驱动涉及棘手的内存和调度问题；块设备实验测试内核的存储路径；DRM Panic 则与崩溃可见性和恢复行为息息相关。

这不再是“Hello World”的领地了。当然，它也不是 Rust 的全面接管。它更接近现实：Rust 正在赢得小范围的信任。在内核文化中，小信任也是件大事。因为在 Linux 内部，没人会免费给予信任，Rust 必须通过代码去赢得它。

Linux 内核不是普通的代码库。网页里的 Bug 会惹恼用户，后端服务的 Bug 会搞崩一个流程，移动应用的 Bug 会招来差评。但内核里的 Bug，能让机器直接宕机。

这是完全不同级别的责任。内核代码触及内存、硬件、驱动、锁、中断、文件系统、网络、进程隔离和设备状态。它必须在内存不足时工作，必须在设备表现异常时工作，必须在“顺境路径”消失时依然工作。

这正是 C 语言既传奇又令人恐惧的地方。C 赋予了开发者力量，真实的力量，锋利的力量。

它让你能贴近机器说话。它赋予你对内存、布局、指针和性能的绝对控制。Linux 之所以是今天的模样，正是因为 C 让这成为可能。

但 C 也太信任人类了。它信任开发者能记住所有权，信任开发者能正确清理，信任开发者能避免 use-after-free 错误，信任开发者会检查每一个错误，信任开发者能正确保护共享状态，信任开发者能把每一个生命周期都装在脑子里。

这实在承载了太多的信任。而人类是会疲惫的，哪怕是天才也一样。

需要注意的是，Rust 并没有消除对技能的需求，没有消除对内核知识的依赖，也没有消除设计工作和所有的 unsafe 代码。

但 Rust 改变了默认的压力。在 C 中，许多安全规则存在于注释、习惯、审查文化和开发者的记忆里。

在 Rust 中，这些规则被转移到了所有权、生命周期、Result、Drop 和类型系统之中。

这就是转变所在。Rust 没有让内核编程变简单，它只是让某些危险错误变得更难被随手写出。这不是炒作，这是工程。

这是我能解释两者差异最清晰的方式。

C 说：“我相信你，小心点。”

Rust 说：“我相信你，但请证明它。”

这听起来很烦人，直到你调试过一个真正的线上问题——每个人都已经很小心了，但 Bug 还是发生了。

小心是不够的。

细心的开发者可能会漏掉一条清理路径；细心的审查者可能会忽略一个生命周期问题；细心的团队可能会带有一个不安全的假设；细心的系统在压力下依然会崩溃。

Rust 的构建基于一种更怀疑的心态：谁拥有这个值？谁可以修改它？这个引用能活多久？如果分配失败怎么办？如果初始化进行到一半停止了怎么办？谁来清理这个资源？这种损坏的状态到底能不能存在？

这种怀疑态度非常有用，尤其是在内核代码中。

因为内核 Bug 往往并不戏剧化，它们看起来很无聊：一个释放后被使用的指针，一个被错误触碰的缓冲区，一个从两个地方同时修改的共享对象，一个提前返回却忘记清理的错误路径。

无聊的错误造成了严重的破坏。Rust 的天赋不在于让程序员变得更聪明，而在于它拒绝让某些糟糕的想法继续隐形。

Rust For Linux 并不意味着 Linux 正在被 Rust 重写。这句话很重要，因为互联网喜欢虚假的战争。

Linux 内核依然主要是 C 语言写的，并且在很长一段时间内都会如此。C 代码不会消失，C 语言的维护者不会离开，关于 C 的知识也不会作废。

Rust For Linux 意味着更谨慎的尝试：它意味着在合理的地方，可以在 Linux 内核中使用 Rust；意味着 Rust 代码可以连接内核 API；意味着 Rust 代码可以遵循内核的构建规则；意味着 Rust 代码可以接受同样严苛的审查文化；意味着驱动和抽象可以用更安全的风格编写；意味着危险的 C API 可以被封装在更安全的 Rust 接口背后。

最后一行才是真正核心的故事。Rust 在 Linux 中的价值不是因为语法好看，而是因为它能创建更安全的边界。内核有一个庞大的 C 世界，Rust 无法神奇地让那个世界变得安全，但 Rust 可以在选定的部分建造受控的门。

这就是安全层诞生的方式：不是通过一次戏剧性的重写，而是通过一次又一次谨慎的边界划定。

Rust For Linux 最重要的理念不是“Rust 代码在内核中运行”。

重要的是边界。原始的 C API 很强大，但很容易被误用。Rust 绑定可以将这些 API 暴露给 Rust 代码，但仅有绑定是不够的，原始绑定依然贴近危险。

更安全的理念是抽象。

Rust 抽象可以将危险的内核概念包装成更难被误用的形态。它可以隐藏 unsafe 细节，强制执行所有权规则，让失败显式化，并在可能的地方让清理自动化。

这就是 Rust 开始成为安全层的原因。不是因为每一行代码都神奇地安全了，而是因为 unsafe 工作被推到了更小、更受审查的角落。

这是一个严肃的设计理念：不再让每个驱动直接接触危险的内部结构，而是构建更安全的路径，并要求新代码走这些路径。

这不仅仅是 Rust 的功劳，这是优秀的工程实践。Rust 只是赋予了内核更强的工具来执行这一理念。

这张图就是整篇文章的缩影。C 依然是心脏，Rust 并没有替换心脏，它是在高风险的新领域周围建造更安全的容器。

这就是为什么“Rust 对决 C”是一场错误的战斗。

更好的问题是：Rust 能在哪里降低风险，同时又不会破坏内核的文化？

这才是严肃的问题，也是 Linux 现在正在缓慢回答的问题。

最重要的基础设施变革起初往往并不戏剧化，它们看起来很无聊：一个驱动被合并，一个抽象得到改进，一个维护者给出反馈，一个示例变得实用，一个子系统尝试了新东西，一个工具链问题被修复。

Linux 就是这样变革的，不是靠打鸡血的演讲。

ASIX PHY 驱动之所以重要，是因为它表明 Rust 不仅仅是一个待在内核旁边的演示语言，它证明了 Rust 可以用于真正的驱动开发工作。

这种进步很容易被低估。人们想要大头条，想要全面重写，想要一场战争，想要一个赢家。

但严肃的系统不会这样改变。它们改变的方式是：一个棘手的问题变得稍微安全了一点，然后另一个，再另一个。

驱动开发是 Rust 证明自己的绝佳领域，因为驱动贴近硬件、内存、状态机和诡异的失败路径。

硬件可不在乎你画得多漂亮的架构图。

设备可能会行为异常，回调可能在你意想不到的时候发生，初始化可能进行到一半失败，清理可能变得复杂，错误路径可能比成功路径更重要。

这就是为什么 Rust 的思维模式很契合。不是因为它让硬件变简单了，而是因为它强迫开发者把更多的真相写进代码里。

如果你想理解为什么 Rust 进入 Linux 很重要，请跳出简单的示例，看看 Android Binder。

Binder 是支撑 Android 大部分功能的进程间通信系统。它不是摆在旁边的装饰性组件，而是应用和系统服务相互通信的核心通道。

这意味着它很繁忙、很敏感、与安全息息相关、与性能息息相关。这恰恰是“内存安全”不再仅仅是个好主意，而是硬性要求的领域。

在这里，Rust 超越了语言偏好的范畴。如果更安全的内核代码能帮助保护数百万设备使用的通道，那么这就不再是开发者的时尚辩论了。

它变成了公共基础设施。这正是这个话题有分量的原因。大多数用户永远不会知道一个驱动是用 C 还是 Rust 写的，他们永远不会读内核邮件列表，也永远不会关心所有权或生命周期。

他们只知道：手机正常使用，机器没有崩溃，数据更安全，设备表现如常。

最好的安全工作是无形的。

Rust For Linux 正在努力成为那种无形的改进。

当 Rust 触及 GPU 驱动工作时，故事变得更有趣了。

GPU 驱动可不是软柿子。它们很复杂，要处理内存，暴露严重的攻击面，应对硬件调度，身处对性能极其敏感的路径，还必须与图形栈的其他部分协同工作。

因此，当 Rust 出现在 Nova 和 Tyr 等 GPU 驱动工作中时，传递的信息就更强烈了。

这不仅是关于编写更安全的示例模块，更是关于探讨 Rust 是否能在复杂性成为常态的地方提供帮助。

这才是 Rust 必须证明自己的地方。不是在干净的示例中，不是在会议的幻灯片里，不是在病毒式传播的推文中，而是在混乱的驱动代码里。如果 Rust 能在那里提供帮助，哪怕很慢，争论的性质就变了。

因为那时，Rust 就不仅仅是“安全”了，它是“有用”的。而“有用”每次都能打败“时髦”。

请注意，这并不是生产级的驱动代码。内核的 Rust API 可能会变动，真正的驱动也需要特定子系统的审查。这个示例仅仅展示了其思维模式：可失败的分配、显式的错误处理、所有权以及清理机制。

这段代码故意写得很简单。它的威力不在于花哨的语法，而在于态度。

try_push 表示分配可能会失败；Result 表示初始化可能不会成功；? 表示失败必须诚实地向上传递；Drop 表示清理工作属于所有权，而不是靠人工记忆内存。

这就是 Rust 的思维模式。

在用户态代码中，人们经常假装分配失败不存在；但在内核工作中，这种幻想是致命的。

内核代码必须尊重失败。Rust 不会让这种尊重仅仅停留在某人的脑海中，它把尊重硬编码进了代码里。这就是为什么它很重要。

本文不是一首 Rust 的赞美诗。Rust 不会修复糟糕的架构，不会消除所有的 unsafe 代码，不会让内核编程变简单，不会取代深厚的子系统知识，不会让每个驱动都正确无误，不会消除审查的需要，不会阻止开发者写出令人困惑的抽象，不会神奇地让 C 代码变安全，也不会解决所有的并发问题。

这种坦诚很重要。因为如果人们过度推销 Rust，只会让严肃的工程师停止倾听。

Rust 不是魔法，它只是针对某些类别错误的更好护栏。但这依然是一件大事。

安全带不能让驾驶零风险，但没有哪个严肃的人会因为事故依然会发生，就说安全带没用。

Rust 在精神上与此类似。它不消除危险，它只是在某些危险变成灾难之前，降低它们的发生概率。这就足够成为我们在乎的理由了。

Rust 在 Linux 中的未来不是由粉丝决定的，而是由维护者决定的。

理应如此。每个子系统都有自己的历史、压力、审查风格和风险等级。有些领域可能会更早欢迎 Rust，有些可能进展缓慢，有些目前可能根本不想要 Rust。

这不是失败，这是负责任的工程态度。

如果 Rust 带来的是额外的工作和微弱的价值，维护者会拒绝它。如果 Rust 能创建安全的抽象、减少重复的错误、改善新驱动的开发，并且不会让审查变得难以忍受，它就会赢得更多空间。

“赢得”是关键词。Rust 必须在 Linux 中赢得自己的位置，不是靠口号，不是靠炒作，不是靠语言自豪感，而是靠维护者可以信任的代码。这就是为什么这个故事如此有趣。Rust 正在进入地球上最严苛的工程文化之一。

没有捷径，没有明星待遇，只有补丁、审查和时间。

我们经常把内存安全当作一个技术特性来谈论，但对我来说，它感觉更私人。

因为在每个严重的 Bug 背后，通常都有一个疲惫的人试图弄清楚到底发生了什么。有人在翻看日志，有人在检查崩溃，有人在解释停机原因，有人在压力下修补错误，有人在纳闷为什么干净的代码会变成崩溃的行为。

软件有时很残酷，它把痛苦隐藏在平静的语法背后。

Rust 不能消除这种痛苦，但它能从地上移除一些陷阱。

因为开发者不是机器，我们会遗忘、会假设、会赶工、会误解。我们相信变量名，会漏掉路径，会以为系统的这一部分拥有某个资源，而另一部分却已经把它释放了。

内核不能仅仅依赖完美的人类，任何严肃的系统都不应该如此。

这就是为什么我喜欢 Rust 进入 Linux 这个想法。不是因为 Rust 很潮，而是因为它感觉像是把“谦卑”变成了一种编程模型。

它承认人类需要帮助。

你可能永远不会写 Linux 驱动，永远不会深入阅读内核源码，也永远不会在内核里构建 Rust。

尽管如此，这个故事依然应该改变你对软件的看法。

其教训绝不是“每个人都必须用 Rust 重写一切”，那是偷懒的思维。真正的教训是：在设计系统时，让做错事变得更困难。

• 在后端系统中，让重复事务更难被处理；
• 在 API 中，让无效状态更难被发送；
• 在数据库中，让破损的关系更难被存储；
• 在事件系统中，让重试和幂等性变得可见；
• 在安全代码中，将危险操作限制在严格的边界之后；
• 在业务逻辑中，让不可能的状态无法被表示。

这是超越了 Rust 本身的 Rust 哲学：安全不仅仅是一种语言特性，安全是一种设计习惯。Rust For Linux 只是最极端的例子，因为内核对幻想毫无耐心。

如果这个理念能在那里存活下来，各地的开发者都应该关注。

我认为在这个时刻，Rust 与 C 的辩论已经显得格局太小了。C 不会消失，C 构建了我们赖以生存的世界，C 依然提供严肃系统所需的控制力，C 背后依然有几十年的工具链、知识和维护者。

但说“C 很强大”并不意味着我们应该忽视它的风险；说“Rust 更安全”也不意味着 Rust 应该取代一切。

这两者可以同时成立：C 可以继续作为 Linux 的心脏，而 Rust 可以成为选定新代码的更安全路径。

这不是矛盾，这是成熟。未来不一定非得是一种语言毁灭另一种语言。未来可以是内核这样说：

“我们知道 C 擅长什么，我们也知道它在哪里让人痛。让我们在安全权衡合理的地方使用 Rust。”

这是成年人的对话。老实说，软件行业需要更多这种成年人的对话。

几十年来，系统编程一直深植一个信念：危险是力量的代价。而 Rust 挑战了这一信念。

它没有说要消除力量，它说力量应该被塑形。

这就是为什么 Rust 进入 Linux 的意义超越了语法。它改变了开发者对系统语言的期望。

也许底层语言可以拥有强大的安全保证；也许内核代码可以暴露更安全的 API 而不失去控制；也许新驱动不需要重蹈每一个古老的内存错误；也许危险代码可以被隔离，而不是散落各处；也许性能和安全并不永远是敌人。

这种思维会蔓延。首先进入驱动，然后进入抽象，接着进入工具链，最后影响内核之外开发者设计系统的方式。

这就是为什么即使是不写 Rust 的人也应该关心这个故事。它在改变标准。一旦开发者体验了更强的护栏，他们就会开始问：为什么其他系统感觉这么松散？

这个问题充满力量。

我不因为人们感到兴奋就相信 Rust For Linux 是真实的。我相信它，是因为它在缓慢推进。

这听起来可能很奇怪，但缓慢的进步往往是严肃基础设施的标志。

快速的炒作烧得快也消失得快；缓慢的采纳会直面现实，会被审查，会惹人烦，会被纠正，最终会变得理所当然。

Linux 不需要 Rust 变得令人兴奋，它需要 Rust 变得可维护。

这意味着 Rust 必须学习内核的文化，融入真实的工作流，尊重子系统的边界，支持真实的硬件，避免创造出维护者讨厌的华而不实的抽象。

这很难。但如果 Rust 能在这个进程中存活下来，它就远不止是一个实验。

它会成为操作系统长期安全故事的一部分。

不是无处不在，不是一蹴而就，而是意义深远。

对于想深入研究的读者，最好的起点是官方的 Rust For Linux 项目、Linux 内核 Rust 文档、Rust 2026 年项目目标，以及围绕 Rust 抽象、参考驱动、Android Binder、ASIX PHY、Nova GPU、Tyr GPU 和安全关键型 Rust 的内核讨论。

不要只看炒作。去读内核文档，读驱动说明，读政策讨论，读真实的代码，也去读那些持怀疑态度的人的论点。

这才是让这个话题变得清晰的途径。你读得越多，真实的故事就越明显。

Rust 不是像名人一样走进 Linux 的，它是像一个带着强力工具的学徒，请求在软件界最艰难的房间里证明自己。这有趣得多了。

最有趣的未来不是一个用 Rust 重写的 Linux 内核。那个想法能骗点击，但不是真实的故事。

真实的未来更安静：C 继续驱动 Linux 的心脏，Rust 在选定的危险边缘生长，新驱动获得了更安全的形态，unsafe 边界变得更小，内核抽象变得更难被误用。某些 Bug 变得更难写出，某些崩溃永远不会发生，某些安全问题永远不会成为头条。

大多数用户永远不会注意到。这正是它重要的原因。伟大的基础设施往往是隐形的。

你不会在手机保持稳定时感谢内存模型，不会在笔记本正确唤醒时感谢驱动，也不会在服务器持续运行时感谢内核。

你只有在基础设施失效时才会注意到它。而 Rust For Linux 正在努力让某些失效变得更不可能发生。这不是一个讨喜的实验，不是一种语言时尚浪潮，不是重写幻想，这是人类有史以来构建的最重要的软件项目之一内部的一场严肃的安全押注。

也许真正的未来不是 C 对决 Rust。也许真正的未来是这样的：C 保持 Linux 心脏的跳动，Rust 成为那些“一次失误代价惨重”之处的护栏。

老实说，这听起来不像是语言战争，更像是成熟。

所以我想问一个令人不适的问题：如果 Linux 正在缓慢接受 Rust 用于危险的新代码，我们还在坚持“纯 C 内核开发”，究竟是因为它在技术上处处更优，还是因为我们在情感上依恋旧有的方式？