全球開發者三年暴增50%！增速最快的不是Python，而是C++和Rust

【CSDN 編者按】在“AI 會不會取代程序員”“C++ 是否不安全”的爭論聲中，很多開發者容易被碎片化輿論帶偏方向。基于此，本文作者從電力、芯片、算力效率等更底層的現實約束出發，結合 2025 年全球開發者數據與一線科技公司高管的真實表態，系統梳理了 C++ 為何在安全質疑、語言競爭與 AI 沖擊下依然保持高速增長。

原文鏈接：https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai/

作者 | Sutter’s Mill 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

2025 年，C++ 再迎豐收之年，數據就是最有力的證明。

在深入解讀數據之前，我們先拋出一個核心問題：2022-2025 年，為何 C++ 與 Rust 能躋身主流編程語言中增長最快的行列？

答案很簡單——縱觀計算機發展史，軟件的消耗增速，始終跑在硬件供給能力的前面。

我們對解決大規模計算問題的需求，一直在不斷突破硬件算力的上限，且這種趨勢看不到終點，這就決定了高性能編程語言的需求會長盛不衰。每隔幾年，總會有人質疑 “硬件性能已經過剩”，但下一個現象級軟件需求的出現，總會給整個行業敲響警鐘——就像 2007 年的 iOS，以及 2022 年 11 月橫空出世的 ChatGPT。

而如今的 AI，正是最新一個“壓榨”硬件性能極限的需求來源。

2025 年全球計算領域的兩大核心瓶頸

先做個小測試：2025 年，制約計算產業發展的兩大核心瓶頸是什么？哪類資源最為緊缺？

不妨先思考幾秒，再繼續往下看……好吧，答案揭曉：如果你的回答是電力與芯片，且順序絲毫不差，那就完全正確。

芯片只是我們的第二大瓶頸。眾所周知，各大超大規模云計算廠商正在為搶奪芯片資源打得不可開交——這也讓英偉達坐穩了全球市值最高公司的寶座，臺積電更是成了牽動全球產業鏈的巨頭，甚至堪稱“全球產業鏈的最大單點風險”。

但很多人都忽略了一點：電力才是 2025 年的頭號瓶頸。你有沒有發現，近期 OpenAI 的所有合作協議，都用 “千兆瓦” 來衡量算力投入？我們不妨看看三位企業高管在最新財報電話會議上的表態。

微軟首席財務官 Amy Hood（2025 年 10 月 29 日 微軟財報電話會議）：

“微軟 Azure 的核心瓶頸，其實并非 GPU 或 CPU 本身的短缺，而是缺乏足夠的場地與電力來部署這些硬件。”

亞馬遜首席執行官Andy Jassy（2025 年 10 月 30 日 亞馬遜財報電話會議）：

“過去 12 個月，AWS 新增了超過 3.8 千兆瓦的電力容量，這一規模遠超其他任何云服務商。更直觀地說，我們現在的電力承載能力，已經是 2022 年的兩倍，并且計劃到 2027 年實現再次翻倍。”

英偉達首席執行官黃仁勛（2025 年 11 月 19 日 英偉達財報電話會議）：

“歸根結底，數據中心的電力上限是固定的——比如一座千兆瓦級數據中心，其電力供給就是 1 千兆瓦。單位功耗的算力表現，將直接決定企業的營收，這是不折不扣的硬道理。”

正因如此，那些能實現“每瓦算力”與“每晶體管算力”最大化的編程語言，未來前景一片光明。過去 80 年，人類想要解決的計算問題規模，始終領先于硬件算力的供給水平；在我看來，未來 80 年這一趨勢也不會改變。

而能同時滿足這兩大核心指標的主流可移植編程語言，屈指可數：C、C++ 與 Rust。因此，2025 年這三門語言均保持穩健增長，尤其是 C++ 與 Rust 的高速擴張，也就不足為奇了。

接下來，我們用數據說話。

2025 年數據洞察：編程領域持續爆發，C++ 與 Rust 領跑增長

編程領域正處于蓬勃發展的風口，程序員崗位的需求呈現長期高速增長的態勢。

SlashData 發布的《2025 年全球開發者群體趨勢報告》顯示，過去三年全球開發者數量增長了約 50%，從 3100 萬出頭飆升至 4700 萬以上。這一數據也得到了其他機構的佐證：IDC 預測，這一增長趨勢將持續，到 2028 年全球開發者數量有望突破 5700 萬；JetBrains 發布的報告也給出了相近的專業開發者數量統計，只是由于統計范圍排除了學生與業余愛好者，整體數值相對更小。

而在 2022—2025 年增速最快的編程語言榜單上，Rust 與 C++ 穩居前兩位。

要理解 C++ 的增長含金量，我們可以從兩個維度來看：

● 橫向對比所有語言：如今 C++ 開發者的總量，已經超過了四年前排名全球第一的編程語言的規模。

● 縱向對比 Rust：C++、Python、Java 這三門語言，單年新增的開發者數量，就與全球 Rust 開發者的總數量大致相當。

C++ 是一門始終在進化的語言，其核心使命就是榨干硬件的每一分性能。為了適應不斷變化的硬件生態，C++ 一直在持續迭代更新。即將發布的 C++26 標準，進一步強化了對最新 CPU 與 GPU 硬件并行性的支持——尤其是新增了更多面向 CPU 內部向量并行的 SIMD 類型，同時引入std::execution Sender/Receiver 模型，以支持多 CPU 與 GPU 的通用并發及并行計算。

看到這里，可能有人會疑惑：這一增長趨勢真的合理嗎？近幾年，不少媒體報道和行業觀點都在唱衰 C++，稱其 “安全性不足，難以滿足現代開發需求”，為何 C++ 還能實現如此強勁的增長？

接下來，我們就來聊聊這個話題。

安全性之爭：類型/內存安全與功能安全

媒體對 C++ 安全漏洞問題的報道，其實存在嚴重夸大。究其原因，一方面是部分報告只統計編程語言層面的漏洞，而這類漏洞在整體安全問題中的占比正逐年下降；另一方面，很多統計數據都將 C 與 C++ 混為一談。我們不妨把這兩個問題拆開來分析。

其一：行業安全問題的核心，并非編程語言本身的安全性缺陷

MITRE 發布的《2025 年 CWE 全球 25 大最危險軟件缺陷榜單》顯示，在排名前十的高危缺陷中，僅有三項與編程語言的安全特性直接相關。而在這三項之中，“越界寫入”與“越界讀取”兩大問題，都能通過 C++26 的增強型標準庫得到顯著改善——C++26 對標準庫進行了加固，為最常用的有界操作新增了邊界檢查機制。更值得注意的是，這份榜單僅統計軟件層面的弱點，而如今越來越多的攻擊手段，已經可以完全繞過軟件層。

為什么漏洞問題越來越不局限于語言或軟件層面？因為軟件的防護能力正在不斷增強，這也直接推高了零日漏洞的利用成本——從數千美元飆升至數百萬美元。在這種情況下，攻擊者自然會轉移目標，尋找防護鏈條中更薄弱的環節。

以 CrowdStrike《2025 年全球威脅報告》為例，該報告指出：79% 的網絡入侵檢測案例，都屬于無惡意軟件攻擊，全程不涉及任何編程語言層面的漏洞利用。與此同時，非語言層面的攻擊手段正在激增，甚至出現了大量非軟件層面的攻擊方式——比如，2024 年下半年語音釣魚（通過電話與語音消息實施釣魚攻擊）的攻擊次數，較上半年暴增了 442%。

相比耗費巨大精力去挖掘一個“釋放后使用”漏洞，編寫惡意代碼植入目標設備（而且這種攻擊的成本還在不斷上升），攻擊者更傾向于選擇更簡單的方式：要么利用不依賴語言缺陷的跨站腳本攻擊，要么干脆完全無視軟件防護，直接通過電話誘騙用戶泄露密碼。

其二：在編程語言相關漏洞中，“罪魁禍首” 是 C 語言，而非 C++

一個關鍵問題在于：絕大多數漏洞統計數據，都將 C 與 C++ 合并計算，很難找到能明確區分兩者的權威公開報告。據我所知，唯一一份能區分 C 與 C++ 安全表現的可靠研究，來自 Mend.io 于 2019 年發布的《全球最安全編程語言排行》。盡管這份數據距今已有數年，但其中體現的趨勢在歷年報告中始終保持一致。

事實上，C++ 的內存安全性，一直更接近現代主流編程語言，而非其 “近親” C 語言。即便如此，C++ 團隊仍在持續優化安全能力——即將發布的 C++26 標準，就帶來了兩大核心安全升級。開發者只需將代碼重新編譯為 C++26 版本，就能獲得顯著的安全性提升：

（1）消除未初始化局部變量導致的未定義行為。這個功能有多實用？就在我撰寫本文的當天，Reddit 的 r/cpp 論壇上還出現了一個吐槽帖：《那個讓我徹底重視未定義行為的生產環境 BUG》，而這個問題恰好能被 C++26 完美解決。

（2）為 C++ 標準庫新增“增強安全模式”的邊界安全檢查。該模式會對最常用的有界操作執行強制邊界校驗。《ACM Queue》2025 年 11 月刊的《生產環境中的實用安全技術》一文指出：蘋果全平臺（包括 WebKit 引擎）與谷歌幾乎所有服務及 Chrome 瀏覽器（代碼規模達數億行），均已大規模部署該特性，且僅帶來了極低的空間與時間開銷（各項開銷占比均不足 1%）。據谷歌預估，僅此一項優化，每年就能幫助其減少 1000-2000 個新 BUG。

除此之外，C++26 還通過 “契約（Contracts）” 機制實現了功能安全——在語言層面引入前置條件、后置條件與契約斷言。開發者可以借助這些特性，對程序行為進行更全面的校驗，其作用遠超單純的內存安全保障。

而在 C++26 之后，我預計相關提案會聚焦于以下方向：

● 進一步強化標準庫的安全防護能力；

● 減少語言中的未定義行為——將其轉化為可檢測的錯誤行為、納入語言層面的契約校驗，或通過 “語言子集（配置文件）” 默認禁用不安全特性，僅允許開發者顯式啟用。

我也聽到不少開發者呼吁：希望 C++ 的演進速度能放緩一些，讓編譯器廠商與用戶有時間消化新特性——就像 C++03 版本那樣，以穩定性為核心目標。但與此同時，大家也十分期待 C++ 的安全性能能持續提升。

所以在這里，我不妨做一個大膽的設想：如果 C++29 版本能聚焦于兩大方向——一是僅修復問題清單中的漏洞、打磨現有特性（不新增功能），二是推進上述“安全強化”計劃（擴展標準庫安全能力、減少語言未定義行為），會怎么樣？

我對這個想法很感興趣。這并非因為安全性是 C++ 的頭號痛點（畢竟 C++ 的使用規模正在高速增長），而是因為它能同時兼顧 “暫緩迭代、穩定現有特性” 與 “持續加固、提升安全性能” 兩大訴求。所謂聚焦，本質就是學會取舍。

結語

編程行業正在高速發展，C++ 更是一騎絕塵。憑借與“計算需求持續超越硬件供給”這一 80 年長周期趨勢的深度契合，C++ 的長期發展前景十分廣闊。作為一門與時俱進的語言，C++ 始終在適配硬件生態的變化，堅守“最大化挖掘硬件潛力”的核心使命，精準滿足開發者的需求。

數據，就是最好的證明。

致敬 C++ 的 2025 年，也期待它在 2026 年續寫輝煌！