微软要对 C++“动刀”了：一场写进软件工程史的重构实验
如果你以为“重写代码”只是某个团队的技术债清理，那你可能低估了这次事件的重量级。
微软正在推进一项跨度接近十年的工程目标：在 2030 年之前，彻底清理核心代码库中的 C / C++，并系统性迁移到 Rust。
这不是一行宣言，而是已经启动的工程化行动，覆盖 Windows、Azure、内核、虚拟化、安全基础设施 等真正的“底盘代码”。
Image
Image
一句狠话，把微软真实目标摊在了台面上
Image
Image
Image
这次把事情捅到台前的人，是微软杰出工程师 Galen Hunt。
在一则招聘信息中，他直截了当地写下了这句话：
我的目标是在 2030 年之前，消除微软代码库中的每一行 C 和 C++。
注意几个关键词：
- 不是新项目不用 C++
- 不是“逐步减少”
- 而是：全部消除
对一家代码规模以“亿行”计、C/C++ 深度嵌入操作系统和云平台的公司来说，这不是升级，是拆迁。
这不是“语言之争”，而是一次工程范式切换
Image
如果你继续往下读 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 年。 而是：我们是否已经开始用新的方式，重新理解“代码”这件事本身。