如果你以为“重写代码”只是某个团队的技术债清理，那你可能低估了这次事件的重量级。

微软正在推进一项跨度接近十年的工程目标：在 2030 年之前，彻底清理核心代码库中的 C / C++，并系统性迁移到 Rust。

这不是一行宣言，而是已经启动的工程化行动，覆盖 Windows、Azure、内核、虚拟化、安全基础设施 等真正的“底盘代码”。

一句狠话，把微软真实目标摊在了台面上

Image

Image

Image

这次把事情捅到台前的人，是微软杰出工程师 Galen Hunt。

在一则招聘信息中，他直截了当地写下了这句话：

我的目标是在 2030 年之前，消除微软代码库中的每一行 C 和 C++。

注意几个关键词：

• 不是新项目不用 C++
• 不是“逐步减少”
• 而是：全部消除

对一家代码规模以“亿行”计、C/C++ 深度嵌入操作系统和云平台的公司来说，这不是升级，是拆迁。

这不是“语言之争”，而是一次工程范式切换

如果你继续往下读 Hunt 的招聘描述，会发现真正的重点不在“Rust”，而在方法论：

• 用 算法 + 图结构 理解海量代码关系
• 用 LLM + Agent 在算法约束下进行代码改写
• 目标是实现一种近乎科幻的效率指标：1 名工程师，1 个月，处理 100 万行代码

这意味着什么？

这意味着微软已经不再把“遗留代码”当作只能靠人肉维护的历史包袱，而是当作可被 AI 规模化治理的工程资产。

为什么是 Rust，而不是“更好的 C++”？

Image

Image

Image

微软给出的理由并不新，但这次是第一次用工程行动下注。

在过去十多年里，微软在多次安全报告中反复确认一个事实：

约 70% 的高危漏洞，来自内存安全问题

而这些问题，几乎都集中在 C / C++ 生态中：

• 缓冲区溢出
• Use-After-Free
• 堆损坏
• 数据竞争
• 野指针

Rust 的价值，并不在“写起来更优雅”，而在于：

• 所有权模型 把内存错误挡在编译期
• 类型系统 强制表达真实约束
• 并发默认安全，而不是“小心点就好”

对操作系统、云基础设施来说，这不是语法偏好，是风险模型的改变。

微软并不是“突然觉醒”

Image

Image

Image

早在 2023 年，微软就在 Windows 内核中引入 Rust：

• 数万行内核代码完成 Rust 化
• DirectWrite Core 库约 15 万行代码迁移
• 性能无退化，稳定性显著提升

微软 Azure CTO Mark Russinovich 甚至公开表示：

未来用于 Windows 和 Azure 的新内核代码，不应再使用 C / C++。

从“试点”到“战略”，Hunt 这次的招聘，意味着事情已经进入 工程化推进阶段。

技术社区的争论，其实早就有答案

Image

Image

Image

当然，争议也随之而来。

有人说： “C++ 本身没问题，问题在开发者。”

甚至 C++ 之父 Bjarne Stroustrup 也指出，现代 C++ 理论上可以做到类型与内存安全。

但微软的选择，其实并不是在回答：

“C++ 能不能写好？”

而是在回答另一个更现实的问题：

在一个拥有数十年历史、数亿行代码、成千上万工程师参与的系统中，哪种方案的整体风险更低？

这不是语言理想主义，而是工程概率论。

真正值得警惕的，不是 Rust，而是“AI + 系统工程”

Image

Image

如果 Galen Hunt 描述的路线最终跑通，那这件事的意义将远超 Rust 本身：

• AI 不再只写“新代码”
• 而是开始重构历史
• 开始介入 操作系统级、基础设施级工程

那些曾被认为“不可触碰”的遗留系统，正在被重新定义为：

可被 AI 规模化治理的对象

2030 年还没到，但方向已经很清楚了。

这场变革，不只是微软的事，它可能会重新定义未来十年的软件工程边界。

写在最后

C / C++ 不会消失，但它们正在从“系统默认选项”，变成“需要被慎重选择的工具”。

而 Rust，也不只是赢了一场语言之争，更像是站在了 AI 驱动软件工程时代的入口。

真正的分水岭，或许不是 2030 年。 而是：我们是否已经开始用新的方式，重新理解“代码”这件事本身。