最近技术圈子里又热闹起来了，起因是 Linus Torvalds 在邮件列表里“怼”了一位想用 Rust 重构内核核心模块的开发者。
这事儿让我想起去年组里那个刚毕业的同事，他拿着《Rust权威指南》跟我说要把整个后端服务用 Rust 重写，理由很充分——“内存安全”。
我当时就问他：你知道重写一个成熟系统意味着什么吗？
三千万行代码不是儿戏，说重写就重写？
Linux 内核如今拥有超过 3000 万行的 C语言 代码，这绝非你周末可以轻松搞定的个人项目。每一行代码背后，都沉淀着几十年的工程智慧，是无数个深夜的 Bug 修复，是生产环境里用真实教训换来的宝贵经验。
你以为重写仅仅是把 C 语法翻译成 Rust 语法吗？这种想法未免过于天真。
那些看起来“不够优雅”的代码，很可能是为了绕过某个特定硬件的奇葩 Bug。那些“不符合现代最佳实践”的写法，也许是在极致性能与可维护性之间做出的艰难权衡。
我见过太多类似的场景：新来的架构师看不上老系统，执意要推倒重来。结果呢？重写了两三年，新系统的稳定性还不如老的，最后只能灰溜溜地回滚。为什么？因为他们严重低估了遗留代码中沉淀的业务逻辑的复杂度。
Rust确实在进入内核，但这绝非一场革命
别误会，我并非否定 Rust 的价值。恰恰相反，Rust 在内核中确实已经获得了一席之地。
从 2022 年的 Linux 6.1 版本开始，Rust 支持就已经正式进入主线了。但观察目前的进展，其主要应用场景依然是编写新的驱动程序，或者构建一些全新的子系统。
原因何在？因为这些都是增量开发，而非存量替换。
用 Rust 写一个新驱动，即使出了问题也大不了回退，不会影响核心功能的运转。但如果你想动调度器、内存管理这些核心模块？那可是牵一发而动全身的事情。
这就像你们公司的核心交易系统，能说重构就重构吗？业务方等着上线新功能，老板盯着 KPI 报表，你敢停机维护三个月试试看？所以，只能在边缘业务或新功能上试水，跑通验证了再考虑慢慢推广。
技术选型从来不只是纯粹的技术问题
说到底，内核 开发使用什么语言，这从来不是一个纯粹的技术决策。
你得考虑开发者生态。全世界有多少熟练的 C 语言开发者？又有多少精通 Rust 的系统级程序员？内核开发本身就是一个相对小众的圈子，如果再人为抬高技术门槛，未来由谁来维护这些代码？
还有工具链成熟度的问题。C 语言的编译器、调试器、性能剖析工具，这套体系已经被打磨了数十年。Rust 的工具链虽然正在飞速进步，但在内核开发这种对稳定性和性能有极端要求的场景下，依然有许多现实问题需要解决。
更实际的一点是，那些维护内核数十年的大佬们，他们写了二三十年的 C，你让他们突然转向 Rust？陡峭的学习曲线是客观存在的。不是他们学不会，而是这个巨大的切换成本，究竟应该由谁来承担？
渐进式演进，才是符合工程智慧的正道
因此，我的判断是：Linux 内核不会被 Rust 完全重写，至少在未来相当长的一段时间内不会。
但 Rust 在内核中的地位会越来越重要，这是一个明确的趋势。
未来更可能的图景是：新增功能优先考虑采用 Rust 实现，而存量老代码则遵循“除非必要，否则不动”的原则。就像许多公司的微服务化改造，不可能一夜之间将庞大的单体应用全部拆解，而是选择一个个相对独立的模块逐步剥离、重构。
这种渐进式的演进策略，才真正符合大型软件工程的实践规律。激进的全盘重写往往结局惨淡，因为在你埋头重写的过程中，原有的系统还在为了满足新需求而不断演进。等你终于“重写”完成，却发现需求早已改变，新系统又变成了需要改造的“老系统”。
技术圈总是热衷于追逐新技术，但真正的工程智慧在于懂得何时该激进创新，何时该保持审慎。Linux 内核能够稳定运行超过三十年，依靠的并非激进，而是极致的稳健。
Rust 的加入无疑是一件好事，它为系统编程带来了更强的安全保证。但我们不能指望它一夜之间改变一切。毕竟，写出能跑的代码相对容易，而维护一个能稳定运行数十年的系统，才是真正的挑战。欢迎大家在 云栈社区 继续交流关于系统编程和语言演进的话题。
发表于 3 小时前
|
查看: 2|
回复: 0
