“我們要徹底告別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 智能體進行規?；a改造。該基礎設施核心已廣泛應用于代碼理解等領域。

　　本次招聘的首席軟件工程師，將助力我們升級基礎設施，實現將微軟核心 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 數據類型?！?/p>

　　當時，他展示的示例代碼說明了要遷移編程語言的部分原因：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 所在團隊在帖子中反復提及“規?；夹g債務”，正是這一邏輯的直接體現。

　　當然，這一目標也并非沒有現實挑戰。C/C++ 在微軟核心系統中的滲透深度極高，涉及性能約束、ABI 兼容性以及復雜的第三方生態。自動化改寫帶來的正確性驗證、回歸測試和風險控制，同樣是難以回避的工程難題。

　　即便如此，微軟仍選擇將這一目標公開化，并綁定明確的時間表。

　　在軟件工程領域，這種做法本身已釋放出一個強烈信號：隨著人工智能與系統工程的深度融合，長期被視為“不可觸碰”的遺留代碼資產，正在被重新納入可規?；卫淼姆懂牎Ｈ绻?Galen Hunt 所描繪的愿景最終得以實現，這不僅將成為一次語言遷移的成功案例，更可能成為 AI 深度介入系統級軟件工程的標志性事件。

　　2030 年尚未到來，但這場圍繞代碼、工具和工程范式的變革，已經在微軟內部悄然啟動。

　　3 “內存安全問題”都是 C++ 的鍋？

　　對于微軟下如此大決心要徹底逃離 C/C++，技術社區反響強烈。

　　其實早在兩年前，微軟 Azure 首席技術官 Mark Russinovich 就曾公開呼吁“在新項目中停止使用 C/C++”，當時他的言論引發了 C++ 愛好者的強烈抗議，其中許多人來自金融服務行業。

　　“C++ 本身沒問題，只是很多使用它（以及其他語言）的人實際上并不懂編程，”一位愛好者說道。

　　“我承認，編寫優秀的 C++ 代碼需要優秀的開發者，而且找到能編寫優秀 Rust 代碼的開發者可能要容易得多。但是，編寫出極其穩定、高度抽象、易于維護且運行速度快的 C++ 代碼是完全可能的，”另一位愛好者說道?！爸皇悄軐懗鰞炐?C++ 代碼的人不多?！?/p>

　　Russinovich 的言論甚至引來了 C++“之父” Bjarne Stroustrup 的回懟。

　　“我們現在可以在 ISO C++ 中實現絕對的類型安全和內存安全，”Bjarne Stroustrup 在接受媒體采訪時說道。Stroustrup 還補充說：“也就是說，每個對象都按照其定義時的類型使用。這意味著我們可以消除懸空指針的使用，捕獲范圍錯誤，并消除數據競爭?！?/p>

　　在 Reddit 平臺上，有用戶創建了一篇帖子探討了 Mark Russinovich 的決定。該用戶稱，“作為一名與 C 語言相伴多年的開發者，此感到非常難以接受。我內心充滿復雜情緒——既理解時代趨勢的必然，又對這段陪伴職業生涯的語言歷史懷有深切眷戀?！?/p>

　　也有 Reddit 用戶表示，C 語言擁有多種應用場景，這是 Rust 無法取代的：

C 語言擁有多種應用場景，這是 Rust 無法取代的。引導程序就是其中之一，它具有非常優秀的編譯性能，并且對于一個不完全兼容的編譯器來說復雜度很低（宏的復雜性和某些未定義行為非常復雜）。 添加更多功能只會讓編譯器編譯速度變慢，并且占用更多內存。 Rust 沒有線性生命周期類型來保證不存在內存泄漏，也沒有非仿射類型來證明對于給定的循環分配模式抽象不存在未定義行為。 這使得 Rust 僅具有更強大的類型系統優勢（許多其他語言也修復了這一點，但 C 拒絕修復語義錯誤的代碼），而其他語言也具有這種優勢。

　　如今微軟這一戰略轉向更是引發了廣泛討論。有 Reddit 用戶犀利反駁：“真正的安全在于嚴謹的工程實踐而非語言本身，難道 Java 項目就沒有漏洞了嗎？” 他強調：

我并非 Rust 程序員，但認為人們將其作用過度神化了——它并非萬能靈藥。例如“棧耗盡”和“堆耗盡”這類問題，在我看來 Rust 并未提供新的解決方案。實際上，諸如堆耗盡及其他各類復雜漏洞，本就需由經驗豐富的程序員在關鍵軟件開發中專門應對。因此，額外關注內存漏洞并不會讓本就錯綜復雜的故障排查工作變得更加困難。 需要說明的是，我始終肯定靜態分析的價值。它不僅在內存漏洞檢測方面，在所有開發場景中都發揮著重要作用。

　　一位在微軟工作了 10 年的開發者在 Hunt 的 LinkedIn 帖子下方留言稱，曾以為借助 AI 技術加上 C++ 標準的迭代無需徹底替換掉它，現在看來不替換不行了。他表示：

　　在微軟工作的十年間，我主要從事進程內存轉儲分析工作，后期還開發了用于自動化分析的事后調試器。這段經歷讓我深切感受到，C/C++ 開發者亟需接受事后調試相關的培訓——這將幫助他們更清楚地理解“哪些做法應當避免”。

　　多年來我所處理的問題類型高度相似，主要可歸結為三類：崩潰類（如釋放后使用、雙重釋放、緩沖區溢出導致的堆損壞）、掛起類（如線程失控、死鎖、孤立線程）以及內存使用異常（如內存泄漏或碎片化）。

　　我曾以為借助人工智能技術，特別是結合 C++ 標準的最新演進，能夠在不必重寫 Rust 代碼的情況下修復這些代碼庫問題?，F在看來這個想法似乎過于樂觀了。

　　個人認為，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 翻譯整理，不代表平臺觀點，未經許可禁止轉載。