作者 ｜冬梅

　　微軟正在推動一項可能重塑整個軟件工程史的長期工程：在 2030 年結束前，徹底消除其核心代碼庫中的 C 和 C++ 代碼，并全面遷移至 Rust 語言。這一目標不僅涉及 Windows、Azure 等關鍵基礎設施，也意味著對全球規(guī)模最大的商業(yè)代碼資產(chǎn)之一進行系統(tǒng)性重構。

　　1 微軟工程師發(fā)帖稱 2030 年前徹底淘汰 C/C++

　　這一目標并非來自外界猜測，而是微軟內(nèi)部核心工程負責人親自對外公開表達的戰(zhàn)略愿景。

　　近日，微軟杰出工程師（Distinguished Engineer）Galen Hunt 在 LinkedIn 上發(fā)布的一則招聘貼文，將這項雄心勃勃的計劃首次清晰地呈現(xiàn)在公眾視野中。

　　根據(jù) LinkedIn 上的個人介紹，Hunt 長期從事系統(tǒng)軟件與操作系統(tǒng)方向的研究與工程實踐，目前的研究重點集中在將大型語言模型（LLM）引入系統(tǒng)軟件領域，以解決長期存在的復雜工程難題。

　　在微軟期間，他創(chuàng)立并領導了Azure Sphere的開發(fā)團隊。Azure Sphere 是微軟面向物聯(lián)網(wǎng)和嵌入式設備推出的端到端安全平臺，旨在使任何設備制造商都能夠構建高度安全的設備。該平臺系統(tǒng)性覆蓋了微軟提出的“高度安全設備的七項核心屬性”，成為微軟在設備安全領域的重要基礎設施之一。

　　在此之前，他是微軟研究院新體驗與技術組織（MSR NExT）啟動階段的核心領導成員之一，負責管理操作系統(tǒng)技術組。更早時期，他曾領導微軟研究院雷德蒙德實驗室的操作系統(tǒng)與分布式系統(tǒng)研究團隊，長期深度參與微軟底層系統(tǒng)技術的前瞻性研究。

　　其研究與工程工作中一個重要方向，是探索虛擬機監(jiān)控器與操作系統(tǒng)內(nèi)核之間的邊界與權衡。圍繞這一問題，他主導了 Drawbridge 項目，嘗試以此構建新型計算系統(tǒng)架構。2012 年至 2013 年間，他曾用一年時間在 Azure 平臺中將 Drawbridge 應用于真實服務部署，該技術隨后也被用于將 Microsoft SQL Service 移植至 Linux 平臺。

　　“我的目標是在 2030 年之前，消除微軟代碼庫中的每一行 C 和 C++ 代碼。”

　　這句話來自 Galen Hunt 本人。

　　對于一家擁有數(shù)十年歷史、代碼規(guī)模以數(shù)億行計、C/C++ 深度嵌入操作系統(tǒng)、數(shù)據(jù)庫、編譯器、虛擬化、安全和云基礎設施的公司而言，這并非一次常規(guī)的技術升級，而是一場系統(tǒng)級、組織級、工具鏈級的工程革命。帖子全文翻譯如下：

　　我的團隊現(xiàn)有一名 IC5 首席軟件工程師職位空缺，工作地點位于雷德蒙德，要求現(xiàn)場辦公。

　　我的目標是在 2030 年前消除微軟所有 C 和 C++ 代碼。我們的策略是融合人工智能與算法技術，重寫微軟最龐大的代碼庫。我們的核心愿景是實現(xiàn)"1 名工程師、1 個月時間、處理 100 萬行代碼"。

　　為完成這項前所未有的任務，我們已構建出強大的代碼處理基礎設施：算法基礎設施能在海量源代碼上創(chuàng)建可擴展的圖譜，而人工智能處理設施則使我們能在算法引導下，運用 AI 智能體進行規(guī)?；a改造。該基礎設施核心已廣泛應用于代碼理解等領域。

　　本次招聘的首席軟件工程師，將助力我們升級基礎設施，實現(xiàn)將微軟核心 C/C++ 系統(tǒng)遷移至 Rust 語言的關鍵目標。該職位硬性要求是具備 Rust 系統(tǒng)級代碼開發(fā)經(jīng)驗（最好有 3 年以上 Rust 系統(tǒng)編程經(jīng)驗），擁有編譯器、數(shù)據(jù)庫或操作系統(tǒng)實現(xiàn)經(jīng)驗者優(yōu)先。雖不強制要求編譯器開發(fā)經(jīng)驗，但候選人需具備在團隊中學習該領域技能的意愿。

　　我們團隊秉持成長型思維模式，成員背景多元、技能全面、視角獨特。我們敢于承擔風險，擅于協(xié)作共贏，始終致力于為內(nèi)外部客戶創(chuàng)造價值。在不斷變革的 AI 工具領域，我們深刻認識到多元化和成長型思維是成功的關鍵。

　　本團隊隸屬于微軟 CoreAI 旗下 EngHorizons 組織的"可擴展軟件工程未來"項目組，核心使命是通過構建先進能力，幫助微軟及客戶實現(xiàn)規(guī)模化技術債務消除。我們通過與內(nèi)部客戶及合作伙伴共同研發(fā)前沿工具與技術，并協(xié)同各產(chǎn)品團隊將這些創(chuàng)新成果推廣至微軟乃至整個行業(yè)。

　　從組織架構上看，Hunt 所在團隊隸屬于微軟 CoreAI 體系下的 Engineering Horizons 部門，項目名稱為“可擴展軟件工程未來”。這一定位并非某個具體產(chǎn)品線的研發(fā)團隊，而更像是一個面向未來的軟件工程能力孵化組織，其目標并不局限于單一系統(tǒng)的遷移，而是試圖構建可在整個微軟內(nèi)部乃至外部客戶中推廣的通用能力。

　　2 為什么要遷移？

　　事實上，Hunt 此次公開表態(tài)，也被視為微軟高層此前相關表述的延續(xù)。該訊號最早放出的時間要追溯到 2023 年。早在 2023 年，微軟就宣布將使用 Rust 重寫部分 Windows 內(nèi)核。

　　微軟副總裁 David Weston 在微軟 Blue Hat IL 2023 上透露，微軟將效仿 Linux，用 Rust 重寫 Windows 內(nèi)核的部分代碼。

　　“我們目前正處于 Rust 在 Windows 中應用的‘爬行、行走、奔跑’階段，” Weston 在微軟 BlueHat IL 2023 大會上表示?！拔覀冋陂_發(fā)地球上最復雜的工程產(chǎn)品之一。但我們的目標是提高安全性……因此，在接下來的幾周或幾個月內(nèi)，外界很可能會看到內(nèi)核中使用 Rust 啟動 Windows，這真的很棒。我們的基本目標是將一些內(nèi)部 C++ 數(shù)據(jù)類型轉換為相應的 Rust 數(shù)據(jù)類型?！?/p>

　　當時，他展示的示例代碼說明了要遷移編程語言的部分原因：Rust 代碼比當前的 C++ 代碼更容易編寫和理解。它也更安全可靠：對于不熟悉 Rust 的人來說，它是一種現(xiàn)代的類 C 編程語言，深受開發(fā)者喜愛，因為它強制創(chuàng)建安全、原生的代碼，而無需像托管語言那樣增加額外的開銷。

　　據(jù) Weston 稱，微軟已經(jīng)用 Rust 重寫了 Windows 內(nèi)核中的 36000 行代碼，此外還用 Rust 重寫了用于概念驗證的 DirectWrite Core 庫的 15.2 萬行代碼，并且性能非常出色，與舊的 C++ 代碼相比沒有任何退化。他還指出，“現(xiàn)在 Windows 內(nèi)核中有一個用 Rust 編寫的系統(tǒng)調(diào)用?！?系統(tǒng)調(diào)用（或稱系統(tǒng)調(diào)用）是用戶模式應用程序與內(nèi)核內(nèi)部函數(shù)交互的方式（簡單來說）。

　　除了 Weston 外，微軟 Azure CTO、技術院士 Mark Russinovich 也曾公開表示，要停止使用 C 和 C+＋ 進行新的內(nèi)核開發(fā)，他表示末來所有用于 Windows 和 Azure 的新內(nèi)核代碼都應該用 Rust 編寫。微軟正在利用大型語言模型推動更加自動化的 C 和 C++ 到 Rust 的轉換流程，以提升系統(tǒng)安全性與工程可維護性。

　　從時間線上看，Russinovich 的發(fā)言更多指向方向性探索，而 Hunt 的招聘和基礎設施描述，則標志著這一方向已經(jīng)進入工程化推進階段。

　　至于為何將 Rust 作為遷移目標語言，微軟并未在此次帖子中展開詳細論證。但結合過去數(shù)年的技術趨勢，其動機并不難理解。

　　微軟在多份安全報告中反復指出，絕大多數(shù)高危安全漏洞源于內(nèi)存安全問題，而這恰恰是 C/C++ 長期存在的結構性弱點。

　　以 2019 年為例，微軟工程師 Matt Miller 在某安全會議上披露，過去 12 年間，微軟每年通過安全更新修復的漏洞中約有 70% 屬于內(nèi)存安全問題。

　　所謂“內(nèi)存安全”，是指應用程序以正確規(guī)范的方式訪問操作系統(tǒng)內(nèi)存；而“內(nèi)存安全漏洞”則指軟件意外或故意越界訪問系統(tǒng)內(nèi)存的行為。

　　經(jīng)常查閱漏洞報告的技術人員會頻繁接觸到以下術語：緩沖區(qū)溢出、競態(tài)條件、頁面錯誤、空指針、棧耗盡、堆耗盡 / 損壞、釋放后使用或雙重釋放等——這些實質上都是內(nèi)存安全漏洞的不同表現(xiàn)形式。

　　如此高比例的漏洞根源在于，主要采用 C/C++ 編寫的 Windows 系統(tǒng)建立在“內(nèi)存不安全”的編程語言基礎之上。這類語言雖然賦予開發(fā)者精細控制內(nèi)存地址的能力，但內(nèi)存管理代碼中的任何細微疏忽都可能導致嚴重漏洞。攻擊者常利用此類漏洞實施遠程代碼執(zhí)行、權限提升等危險入侵。當前，內(nèi)存安全漏洞已成為黑客最主要的攻擊入口，其中釋放后使用和堆損壞漏洞尤其受到攻擊者青睞，成為其開發(fā)攻擊程序時最常利用的突破口。

　　Rust 通過所有權模型和編譯期檢查機制，在語言層面系統(tǒng)性降低了內(nèi)存錯誤和數(shù)據(jù)競爭風險，這對于操作系統(tǒng)、云基礎設施和虛擬化平臺而言，具有直接且可量化的安全收益。

　　更重要的是，微軟面對的是一個跨越數(shù)十年的超大型遺留系統(tǒng)集合。在這種背景下，Rust 在類型系統(tǒng)、工具鏈一致性和長期維護成本方面的優(yōu)勢，也被視為解決技術債務問題的重要路徑。Hunt 所在團隊在帖子中反復提及“規(guī)?；夹g債務”，正是這一邏輯的直接體現(xiàn)。

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

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

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

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

　　3 “內(nèi)存安全問題”都是 C++ 的鍋？

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

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

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

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

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

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

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

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

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

　　如今微軟這一戰(zhàn)略轉向更是引發(fā)了廣泛討論。有 Reddit 用戶犀利反駁：“真正的安全在于嚴謹?shù)墓こ虒嵺`而非語言本身，難道 Java 項目就沒有漏洞了嗎？” 他強調(diào)：

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

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

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

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

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

　　個人認為，UMDF（用戶模式驅動程序框架）的引入是 Windows 系統(tǒng)最后一次重大變革，它顯著降低了藍屏死機（BSOD）的發(fā)生頻率。

　　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 翻譯整理，不代表平臺觀點，未經(jīng)許可禁止轉載。