但要说取代C？不会发生。2026年不会，十年后不会，可能永远不会。
人们觉得Rust会取代C的逻辑很简单：C有内存安全问题，缓冲区溢出、释放后使用、空指针解引用，这些造成了历史上最严重的安全灾难。微软、谷歌、Linux内核团队都公开承认，大量漏洞源于C和C++的内存安全问题。然后Rust带着无需垃圾回收的内存安全、编译时捕获bug的所有权机制、现代化工具链出现了。人们自然会想：Rust就是更好的C，一切终将迁移过去。
逻辑在这里断裂了。
C不只是代码，它是基础设施本身。操作系统内核、设备驱动、嵌入式固件、引导程序、网络协议栈、微控制器、BIOS和UEFI、Python和Ruby和Node.js的运行时，这些不是你能在一个迭代周期内重构的小型Web应用。它们是运行了几十年、经过实战检验的庞大系统，驱动着汽车、医疗设备、飞机、工业设备、电网。
重写是危险的，是昂贵的。当你处理的是生命攸关或安全攸关的系统时，“用新语言重来一遍”是大多数人承担不起的赌博。
还有一点很多人没想过：C是几乎所有事物之间的接口。如果你想让两种不同的语言或系统相互通信，它们通常通过C来实现。Python调用C库，Rust调用C库，Go、Java、JavaScript都有对C的外部函数接口。C存在太久、运行在太多平台上，它基本上就是通用翻译器。Rust有很好的C互操作性，但这恰恰说明了问题：Rust依赖于C的存在。它不是在消除C，而是在C之上、之旁、之周围构建。如果C明天消失，整个软件栈都会崩塌。
Rust的安全性是真实的，但不是免费的。你要为此付出复杂性的代价：所有权、生命周期、借用规则都很难学。有时候借用检查器会跟你较劲，即使你清楚自己在做什么。而C很简单，不安全，但简单。没有生命周期，没有借用检查器，只有指针、结构体和函数。在某些场景下，简单比安全更重要：内存极度受限的微型嵌入式系统、Rust工具链尚未覆盖的冷门硬件平台、在最底层工作的引导程序和固件。
很多人幻想的路径是：找一个C代码库，用Rust重写，然后收获成果。现实是：那个C代码库可能有几十万行，可能编码了几十年的领域知识和bug修复，可能有连文档都没有的怪异行为。一次糟糕的Rust重写可能引入新的bug，和原来的内存问题一样严重。
2026年真正发生的是：Linux内核有了Rust支持，不是Rust重写，而是Rust与C并存。驱动和模块可以用Rust写，核心仍然是C。微软和谷歌在部分技术栈中试验Rust，但他们没有丢弃C代码，而是在合适的地方添加Rust，在有效的地方保留C。嵌入式和固件开发者在谨慎探索Rust，但C仍是默认选择，因为工具链成熟、生态庞大、语言足够小巧能适应严苛约束。
如果你只学Rust而跳过C，你会错过一些重要的东西。C教会你内存实际如何工作、指针底层在做什么、操作系统和硬件如何交互、为什么某些东西快而另一些慢。当你懂C时，Rust更有意义。你理解借用检查器为何存在，知道它在保护你免受什么。当你只懂Rust时，语言感觉像是你必须遵守的魔法规则。当你先懂C时，Rust感觉像是你已经理解的危险道路上的护栏。
C不是遗留知识，它是上下文。这个上下文让你更擅长Rust，更擅长调试，更擅长理解系统。
“Rust对C”的辩论令人疲惫，因为这是个错误的问题。真正的工程师不问“哪种语言赢”，他们问“哪种工具适合这个问题”。有时是C，有时是Rust，有时是两者协同工作。
C构建了我们生活的世界。Rust正在帮助我们更安全地构建下一层，同时不牺牲性能。它们不是敌人，它们是代际传承。
计算世界足够大，容得下两者。
