“我们要彻底告别C++”！微软启动代码史上最大“拆迁”：Windows、Azure将用Rust重写

　　作者 ｜冬梅

　　微软正在推动一项可能重塑整个软件工程史的长期工程：在 2030 年结束前，彻底消除其核心代码库中的 C 和 C++ 代码，并全面迁移至 Rust 语言。这一目标不仅涉及 Windows、Azure 等关键基础设施，也意味着对全球规模最大的商业代码资产之一进行系统性重构。

　　1 微软工程师发帖称 2030 年前彻底淘汰 C/C++

　　这一目标并非来自外界猜测，而是微软内部核心工程负责人亲自对外公开表达的战略愿景。

　　近日，微软杰出工程师（Distinguished Engineer）Galen Hunt 在 LinkedIn 上发布的一则招聘贴文，将这项雄心勃勃的计划首次清晰地呈现在公众视野中。

　　根据 LinkedIn 上的个人介绍，Hunt 长期从事系统软件与操作系统方向的研究与工程实践，目前的研究重点集中在将大型语言模型（LLM）引入系统软件领域，以解决长期存在的复杂工程难题。

　　在微软期间，他创立并领导了Azure Sphere的开发团队。Azure Sphere 是微软面向物联网和嵌入式设备推出的端到端安全平台，旨在使任何设备制造商都能够构建高度安全的设备。该平台系统性覆盖了微软提出的“高度安全设备的七项核心属性”，成为微软在设备安全领域的重要基础设施之一。

　　在此之前，他是微软研究院新体验与技术组织（MSR NExT）启动阶段的核心领导成员之一，负责管理操作系统技术组。更早时期，他曾领导微软研究院雷德蒙德实验室的操作系统与分布式系统研究团队，长期深度参与微软底层系统技术的前瞻性研究。

　　其研究与工程工作中一个重要方向，是探索虚拟机监控器与操作系统内核之间的边界与权衡。围绕这一问题，他主导了 Drawbridge 项目，尝试以此构建新型计算系统架构。2012 年至 2013 年间，他曾用一年时间在 Azure 平台中将 Drawbridge 应用于真实服务部署，该技术随后也被用于将 Microsoft SQL Service 移植至 Linux 平台。

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

　　这句话来自 Galen Hunt 本人。

　　对于一家拥有数十年历史、代码规模以数亿行计、C/C++ 深度嵌入操作系统、数据库、编译器、虚拟化、安全和云基础设施的公司而言，这并非一次常规的技术升级，而是一场系统级、组织级、工具链级的工程革命。帖子全文翻译如下：

　　我的团队现有一名 IC5 首席软件工程师职位空缺，工作地点位于雷德蒙德，要求现场办公。

　　我的目标是在 2030 年前消除微软所有 C 和 C++ 代码。我们的策略是融合人工智能与算法技术，重写微软最庞大的代码库。我们的核心愿景是实现"1 名工程师、1 个月时间、处理 100 万行代码"。

　　为完成这项前所未有的任务，我们已构建出强大的代码处理基础设施：算法基础设施能在海量源代码上创建可扩展的图谱，而人工智能处理设施则使我们能在算法引导下，运用 AI 智能体进行规模化代码改造。该基础设施核心已广泛应用于代码理解等领域。

　　本次招聘的首席软件工程师，将助力我们升级基础设施，实现将微软核心 C/C++ 系统迁移至 Rust 语言的关键目标。该职位硬性要求是具备 Rust 系统级代码开发经验（最好有 3 年以上 Rust 系统编程经验），拥有编译器、数据库或操作系统实现经验者优先。虽不强制要求编译器开发经验，但候选人需具备在团队中学习该领域技能的意愿。

　　我们团队秉持成长型思维模式，成员背景多元、技能全面、视角独特。我们敢于承担风险，擅于协作共赢，始终致力于为内外部客户创造价值。在不断变革的 AI 工具领域，我们深刻认识到多元化和成长型思维是成功的关键。

　　本团队隶属于微软 CoreAI 旗下 EngHorizons 组织的"可扩展软件工程未来"项目组，核心使命是通过构建先进能力，帮助微软及客户实现规模化技术债务消除。我们通过与内部客户及合作伙伴共同研发前沿工具与技术，并协同各产品团队将这些创新成果推广至微软乃至整个行业。

　　从组织架构上看，Hunt 所在团队隶属于微软 CoreAI 体系下的 Engineering Horizons 部门，项目名称为“可扩展软件工程未来”。这一定位并非某个具体产品线的研发团队，而更像是一个面向未来的软件工程能力孵化组织，其目标并不局限于单一系统的迁移，而是试图构建可在整个微软内部乃至外部客户中推广的通用能力。

　　2 为什么要迁移？

　　事实上，Hunt 此次公开表态，也被视为微软高层此前相关表述的延续。该讯号最早放出的时间要追溯到 2023 年。早在 2023 年，微软就宣布将使用 Rust 重写部分 Windows 内核。

　　微软副总裁 David Weston 在微软 Blue Hat IL 2023 上透露，微软将效仿 Linux，用 Rust 重写 Windows 内核的部分代码。

　　“我们目前正处于 Rust 在 Windows 中应用的‘爬行、行走、奔跑’阶段，” Weston 在微软 BlueHat IL 2023 大会上表示。“我们正在开发地球上最复杂的工程产品之一。但我们的目标是提高安全性……因此，在接下来的几周或几个月内，外界很可能会看到内核中使用 Rust 启动 Windows，这真的很棒。我们的基本目标是将一些内部 C++ 数据类型转换为相应的 Rust 数据类型。”

　　当时，他展示的示例代码说明了要迁移编程语言的部分原因：Rust 代码比当前的 C++ 代码更容易编写和理解。它也更安全可靠：对于不熟悉 Rust 的人来说，它是一种现代的类 C 编程语言，深受开发者喜爱，因为它强制创建安全、原生的代码，而无需像托管语言那样增加额外的开销。

　　据 Weston 称，微软已经用 Rust 重写了 Windows 内核中的 36000 行代码，此外还用 Rust 重写了用于概念验证的 DirectWrite Core 库的 15.2 万行代码，并且性能非常出色，与旧的 C++ 代码相比没有任何退化。他还指出，“现在 Windows 内核中有一个用 Rust 编写的系统调用。” 系统调用（或称系统调用）是用户模式应用程序与内核内部函数交互的方式（简单来说）。

　　除了 Weston 外，微软 Azure CTO、技术院士 Mark Russinovich 也曾公开表示，要停止使用 C 和 C+＋ 进行新的内核开发，他表示末来所有用于 Windows 和 Azure 的新内核代码都应该用 Rust 编写。微软正在利用大型语言模型推动更加自动化的 C 和 C++ 到 Rust 的转换流程，以提升系统安全性与工程可维护性。

　　从时间线上看，Russinovich 的发言更多指向方向性探索，而 Hunt 的招聘和基础设施描述，则标志着这一方向已经进入工程化推进阶段。

　　至于为何将 Rust 作为迁移目标语言，微软并未在此次帖子中展开详细论证。但结合过去数年的技术趋势，其动机并不难理解。

　　微软在多份安全报告中反复指出，绝大多数高危安全漏洞源于内存安全问题，而这恰恰是 C/C++ 长期存在的结构性弱点。

　　以 2019 年为例，微软工程师 Matt Miller 在某安全会议上披露，过去 12 年间，微软每年通过安全更新修复的漏洞中约有 70% 属于内存安全问题。

　　所谓“内存安全”，是指应用程序以正确规范的方式访问操作系统内存；而“内存安全漏洞”则指软件意外或故意越界访问系统内存的行为。

　　经常查阅漏洞报告的技术人员会频繁接触到以下术语：缓冲区溢出、竞态条件、页面错误、空指针、栈耗尽、堆耗尽 / 损坏、释放后使用或双重释放等——这些实质上都是内存安全漏洞的不同表现形式。

　　如此高比例的漏洞根源在于，主要采用 C/C++ 编写的 Windows 系统建立在“内存不安全”的编程语言基础之上。这类语言虽然赋予开发者精细控制内存地址的能力，但内存管理代码中的任何细微疏忽都可能导致严重漏洞。攻击者常利用此类漏洞实施远程代码执行、权限提升等危险入侵。当前，内存安全漏洞已成为黑客最主要的攻击入口，其中释放后使用和堆损坏漏洞尤其受到攻击者青睐，成为其开发攻击程序时最常利用的突破口。

　　Rust 通过所有权模型和编译期检查机制，在语言层面系统性降低了内存错误和数据竞争风险，这对于操作系统、云基础设施和虚拟化平台而言，具有直接且可量化的安全收益。

　　更重要的是，微软面对的是一个跨越数十年的超大型遗留系统集合。在这种背景下，Rust 在类型系统、工具链一致性和长期维护成本方面的优势，也被视为解决技术债务问题的重要路径。Hunt 所在团队在帖子中反复提及“规模化消除技术债务”，正是这一逻辑的直接体现。

　　当然，这一目标也并非没有现实挑战。C/C++ 在微软核心系统中的渗透深度极高，涉及性能约束、ABI 兼容性以及复杂的第三方生态。自动化改写带来的正确性验证、回归测试和风险控制，同样是难以回避的工程难题。

　　即便如此，微软仍选择将这一目标公开化，并绑定明确的时间表。

　　在软件工程领域，这种做法本身已释放出一个强烈信号：随着人工智能与系统工程的深度融合，长期被视为“不可触碰”的遗留代码资产，正在被重新纳入可规模化治理的范畴。如果 Galen Hunt 所描绘的愿景最终得以实现，这不仅将成为一次语言迁移的成功案例，更可能成为 AI 深度介入系统级软件工程的标志性事件。

　　2030 年尚未到来，但这场围绕代码、工具和工程范式的变革，已经在微软内部悄然启动。

　　3 “内存安全问题”都是 C++ 的锅？

　　对于微软下如此大决心要彻底逃离 C/C++，技术社区反响强烈。

　　其实早在两年前，微软 Azure 首席技术官 Mark Russinovich 就曾公开呼吁“在新项目中停止使用 C/C++”，当时他的言论引发了 C++ 爱好者的强烈抗议，其中许多人来自金融服务行业。

　　“C++ 本身没问题，只是很多使用它（以及其他语言）的人实际上并不懂编程，”一位爱好者说道。

　　“我承认，编写优秀的 C++ 代码需要优秀的开发者，而且找到能编写优秀 Rust 代码的开发者可能要容易得多。但是，编写出极其稳定、高度抽象、易于维护且运行速度快的 C++ 代码是完全可能的，”另一位爱好者说道。“只是能写出优秀 C++ 代码的人不多。”

　　Russinovich 的言论甚至引来了 C++“之父” Bjarne Stroustrup 的回怼。

　　“我们现在可以在 ISO C++ 中实现绝对的类型安全和内存安全，”Bjarne Stroustrup 在接受媒体采访时说道。Stroustrup 还补充说：“也就是说，每个对象都按照其定义时的类型使用。这意味着我们可以消除悬空指针的使用，捕获范围错误，并消除数据竞争。”

　　在 Reddit 平台上，有用户创建了一篇帖子探讨了 Mark Russinovich 的决定。该用户称，“作为一名与 C 语言相伴多年的开发者，此感到非常难以接受。我内心充满复杂情绪——既理解时代趋势的必然，又对这段陪伴职业生涯的语言历史怀有深切眷恋。”

　　也有 Reddit 用户表示，C 语言拥有多种应用场景，这是 Rust 无法取代的：

C 语言拥有多种应用场景，这是 Rust 无法取代的。引导程序就是其中之一，它具有非常优秀的编译性能，并且对于一个不完全兼容的编译器来说复杂度很低（宏的复杂性和某些未定义行为非常复杂）。 添加更多功能只会让编译器编译速度变慢，并且占用更多内存。 Rust 没有线性生命周期类型来保证不存在内存泄漏，也没有非仿射类型来证明对于给定的循环分配模式抽象不存在未定义行为。 这使得 Rust 仅具有更强大的类型系统优势（许多其他语言也修复了这一点，但 C 拒绝修复语义错误的代码），而其他语言也具有这种优势。

　　如今微软这一战略转向更是引发了广泛讨论。有 Reddit 用户犀利反驳：“真正的安全在于严谨的工程实践而非语言本身，难道 Java 项目就没有漏洞了吗？” 他强调：

我并非 Rust 程序员，但认为人们将其作用过度神化了——它并非万能灵药。例如“栈耗尽”和“堆耗尽”这类问题，在我看来 Rust 并未提供新的解决方案。实际上，诸如堆耗尽及其他各类复杂漏洞，本就需由经验丰富的程序员在关键软件开发中专门应对。因此，额外关注内存漏洞并不会让本就错综复杂的故障排查工作变得更加困难。 需要说明的是，我始终肯定静态分析的价值。它不仅在内存漏洞检测方面，在所有开发场景中都发挥着重要作用。

　　一位在微软工作了 10 年的开发者在 Hunt 的 LinkedIn 帖子下方留言称，曾以为借助 AI 技术加上 C++ 标准的迭代无需彻底替换掉它，现在看来不替换不行了。他表示：

　　在微软工作的十年间，我主要从事进程内存转储分析工作，后期还开发了用于自动化分析的事后调试器。这段经历让我深切感受到，C/C++ 开发者亟需接受事后调试相关的培训——这将帮助他们更清楚地理解“哪些做法应当避免”。

　　多年来我所处理的问题类型高度相似，主要可归结为三类：崩溃类（如释放后使用、双重释放、缓冲区溢出导致的堆损坏）、挂起类（如线程失控、死锁、孤立线程）以及内存使用异常（如内存泄漏或碎片化）。

　　我曾以为借助人工智能技术，特别是结合 C++ 标准的最新演进，能够在不必重写 Rust 代码的情况下修复这些代码库问题。现在看来这个想法似乎过于乐观了。

　　个人认为，UMDF（用户模式驱动程序框架）的引入是 Windows 系统最后一次重大变革，它显著降低了蓝屏死机（BSOD）的发生频率。

　　https://www.thurrott.com/dev/330980/microsoft-to-replace-all-c-c-code-with-rust-by-2030

　　https://www.thurrott.com/windows/282471/microsoft-is-rewriting-parts-of-the-windows-kernel-in-rust

　　https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/

　　声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。