未来Linux Kernel 会不会用Rust 重写?

大家好，我是良许

最近在技术圈又炸了，起因是Linus在邮件列表里怼了一个想用Rust重构核心模块的开发者。

这事儿让我想起去年组里那个刚毕业的小伙，拿着《Rust权威指南》跟我说要把整个后端服务用Rust重写，理由是"内存安全"。

我当时就问他一句：你知道重写意味着什么吗？

三千万行代码不是说重写就重写的

Linux内核现在有超过3000万行C代码，这可不是你周末能撸完的个人项目。

每一行代码背后都是几十年的工程智慧，是无数个深夜的bug修复，是生产环境里用血泪换来的经验。

你以为重写只是把C语法翻译成Rust语法？

太天真了。

那些看起来"不优雅"的代码，可能是为了绕过某个特定硬件的奇葩bug。

那些"不符合最佳实践"的写法，可能是在性能和可维护性之间做的艰难取舍。

我见过太多这样的场景：新来的架构师看不惯老系统，非要推倒重来。

结果呢？重写了两年，新系统还没老系统稳定，最后灰溜溜地回滚。

为什么？因为他们低估了legacy code里沉淀的业务逻辑复杂度。

Rust确实在进内核，但这不是革命

别误会，我不是说Rust不好。

恰恰相反，Rust在内核里确实有一席之地。

从2022年Linux 6.1开始，Rust就正式进入主线了。但你看看现在的进展，主要还是在写驱动程序，搞一些新的子系统。

为什么？

因为这些是增量开发，不是存量替换。

写新驱动用Rust，出了问题大不了回退，不影响核心功能。

但你要动调度器、内存管理这些核心模块？那可是牵一发而动全身的事。

这就像你们公司的核心交易系统，能说重构就重构吗？

业务方等着用，老板盯着KPI，你敢停机维护三个月试试？

所以只能在边缘业务试水，跑通了再慢慢推广。

技术选型从来不只是技术问题

说到底，用什么语言写内核，这不是个纯技术问题。

你得考虑开发者生态。

全世界有多少人会写C？又有多少人精通Rust？

内核开发本来就是个小圈子，你再把门槛抬高，谁来维护代码？

还有工具链的问题。C的编译器、调试器、性能分析工具，这套体系打磨了几十年。

Rust的工具链虽然在快速进步，但在内核这种极端场景下，还有很多坑要填。

更现实的是，那些维护内核的大佬们，人家写了二三十年C，你让他们突然转Rust？

学习曲线在那摆着呢。不是说学不会，而是这个切换成本谁来承担？

渐进式演进才是正道

所以我的判断是：Linux内核不会被Rust完全重写，至少在可预见的未来不会。

但Rust会在内核里占据越来越重要的位置，这是趋势。

未来可能的场景是：新功能优先考虑Rust，老代码该动才动。

就像你们公司的微服务改造，不可能一夜之间把单体应用全拆了，而是一个模块一个模块地剥离。

这种渐进式演进才符合工程实践。

激进的重写往往死得很惨，因为你在重写的过程中，原有系统还在不断演进，等你写完了，需求又变了。

这就是为什么那么多重构项目最后都烂尾。

技术圈总喜欢追新，但真正的工程智慧是知道什么时候该激进，什么时候该保守。

Linux内核能跑三十多年，靠的不是激进，而是稳健。

Rust的加入是好事，但别指望它能一夜之间改变什么。

毕竟，写代码容易，维护代码难。

能跑三十年的系统，才是真正的牛逼。