2022 年出現了許多可以與 C++ 競爭的語言。就在今年的 CPP North C++ 大會上，谷歌宣布了一門新的編程語言 Carbon，并稱其將是「C++ 的繼任者」。

對于這一事件，國外媒體和開發者們也詢問了 C++ 之父 Bjarne Stroustrup 的看法，他表示：“這些年總是有新的語言試圖成為 C++ 的繼承者，我歡迎對編程語言和編程風格進行實驗。但 Carbon 太新且規范不足，我無法真正做出有意義的技術評論。而通常在不開發全新語言規則、庫和管理方案的情況下，很難提供 C++ 的替代方案。”

該語言發出后，也讓一眾網友淺來圍觀，有支持，也有反對的聲音。

近日，Garmin 的一名軟件工程師 Lucian Radu Teodorescu 在文章中報道了目前 C++ 繼任語言的技術狀況。

C++ 是一種特殊的編程語言，也是最常用的編程語言之一，但它也是最受批評的語言之一。根據 TIOBE 指數，30 年來，C++ 一直是排名前 4 的編程語言（使用12個月的平均值），并且還成功摘得了 2022 年的年度編程語言稱號。

參見下圖，可了解過去 20 年的語言趨勢（2022年10月的TIOBE編程社區指數）。

對于一種已經存在了近 40 年的編程語言來說，能經常出現在頂級編程語言的名單中，的確是一個偉大的成就。在頗受歡迎的同時，C++ 的批評聲卻接連不斷，例如 Liunx 之父直接說 C++ 是一門糟糕的語言。大部分的人都在抱怨這種語言太大了，太復雜了，有一些是應該被扼殺的功能，有太多的功能，反之，又有些功能不夠用。以偏概全，C++ 可以被看作是一個沒有清晰連貫的故事的各種功能的隨機集合。

在為該語言辯護時，Bjarne Stroustrup 認為，"在 C++ 中，有一種更小、更干凈的語言正在努力擺脫"。這句話在 28 年后的今天仍然被廣泛使用。雖然這句話意在為 C++ 辯護，但如果仔細分析一下，就會發現這也是一種隱含的批評。C++ 仍然沒有成為人們所期望的那種更小、更干凈的語言。它可能僅僅意味著這種更小更干凈的語言只是一個海市蜃樓。

1、意欲取代 C++ 的編程語言

那么問題來了，怎樣才能獲得一個更好的編程語言呢？它比現在的 C++ 更簡單、更干凈，并且與 C++ 占據同樣的空間（系統編程語言）？一個 C++ 的繼任語言是什么樣子的？

雖然過去也有一些嘗試，但像 2022 年這樣的還是很少見的，一下子有 3 種繼任者語言在 C++ 主題演講中公布。

首先，有 Dave Abrahams 和 Dimitri Racordon 在 C++ Now 上宣布的 Val。Val 的核心思想是，我們可以使用可變值語義建立安全且高效的程序。

兩個月后，在 CppNorth 上，Chandler Carruth 宣布了 Carbon 語言。Carbon 語言試圖解決 C++ 的幾個方面：幾十年來積累的技術債務、優先考慮向后兼容性和 C++ 的進化過程。

又過了兩個月，在 CppCon 上，Herb Sutter 宣布了 CppFront，作為 C++ 的可能繼承者。他的主要目標是 "使 C++ 本身向前發展，并使 C++ 加倍發展"，防止用戶遷移到其他語言。宣稱的目標是使 C++ 的安全性提高 50 倍，簡單 10 倍。

本文作者 Lucian Radu Teodorescu 試圖對這三種語言提供一個批判性的觀點。他解釋道：“這樣做并不是認為它們不能成為 C++ 的繼承者；恰恰相反，我試圖在希望取代 C++ 的位置之前列出這些語言在需要解決的問題。雖然我確實有一些個人偏見，但我會盡力客觀地進行分析。”

2、 早期取代者

D 編程語言由 Walter Bright 創建，出現在 2001 年；在 2007 年時，Andrei Alexandrescu 加入了設計和開發工作。這種語言本應從 C++ 的錯誤中學習，并成為其繼承者。它承諾了同樣的效率水平，但增加了大量的新功能，并簡化了 C++ 的一些更復雜的部分。D 的主頁將 D 宣傳為一種可以 "寫得快、讀得快、跑得快 "的語言。

D 已經吸引了一些商業用戶，但可以說它并沒有達到重要的編程語言的地位。Andrei 是作者長期以來的偶像之一，而且對 Walter 相當尊敬，但主要把 D 看作是一個語言功能的大集合，松散地綁在一起。在我看來，這門語言缺乏一個清晰的基礎，可以讓所有的功能都有凝聚力。

Go 編程語言于 2009 年由谷歌推出；1.0 版本于 2012 年發布。這種語言的目標是讓程序員 "大規模地構建快速、可靠和高效的軟件"。Go 語言的設計者不喜歡 C++，因此，Go 似乎更像是 C 的進化，而不是 C++ 的進化。Go 在 2022 年才增加了泛型，并且仍然缺乏廣泛使用的功能，如異常處理。

雖然 Go 可以說是一種成功的編程語言，但它的成功主要是在云計算業務中。盡管它取得了相對的成功，但它不能被稱為 C++ 的繼承者。

Rust 是 Mozilla 開發的一種編程語言，2010 年時公布，第一個版本在 2015 年發布。Rust 專注于可靠（內存和線程安全）和高效的軟件。Rust 語言模型是圍繞著所謂的借用檢查器，它能跟蹤所有對象的生命周期；因此，它可以在編譯時檢測安全錯誤，并不需要使用垃圾收集器。

Rust 雖然不像 Go 那樣流行，但似乎被認為是 C++ 的良好替代品。問題是，Rust 和 C++ 之間沒有清晰/干凈/通用的接口方式，這使得想轉到 Rust 的 C++ 程序員經歷了突然的遷移。

3、 Val

Val 給自己的目標定位是：

快速的定義

默認情況下是安全的

簡單

可與 C++互操作

Val 以這些目標針對 C++、Rust 和 Swift 語言的受眾。它的目標是實現 C++ 的性能，但要比 Rust 更簡單的方式保證安全。在性能方面，Val 旨在減少編寫安全軟件所需的對象復制和內存分配的數量。在安全性方面，Val 中的所有結構都保證是安全的，除非用戶明確要求額外的控制（將代碼的一部分標記為不安全）。該語言的簡單性主要來自于它對 Swift 的強烈影響，通常被認為是一種簡單易用的語言。

許多編程語言不一定有一個貫穿其所有功能的核心思想，就像語言的催化劑一樣；這會給人的印象是這些語言缺乏連貫性。這不能說是 Val 的問題。這門語言突出之處在于它有一個模型可以在程序上消除安全問題：它被稱為 Mutable Value Semantics（變值語義）。但是，在這之前，一起先來探討一下它所解決的主要問題。

C++ 本質上是不安全的

這一切都始于這樣的觀察：在存在突變的情況下，引用語義可能會導致不安全的程序。因為引用語義允許創建復雜的依賴關系圖，所以突變不能保證在整個圖中保留安全性。例如，如果一個函數對兩個對象進行操作并改變了其中一個對象時，就不能保證另一個對象不會以完全意想不到的方式發生變化。這在單線程和多線程環境中都會產生問題。此外，如果不深入檢查所有可能受到影響的代碼，程序員們也沒有系統的方法來驗證突變的后果。這簡直打破了結構化編程的核心思想。

以下面這個 C++ 代碼片段為例：

void append_vec(vector& dest, const vector& src) { for ( auto x: src ) dest.push_back(x); }

忽略執行中的低效率，這段代碼有一個嚴重的安全問題。而且，如果只看這段代碼，就不容易發現這個問題；還必須看一下周圍的代碼。如果此函數的調用者提供相同的向量作為源參數和目標參數，那么就會導致未定義的行為。

為了確保像這樣的函數有正確的語義，則需要一個獨立性的保證：程序員們需要確保所交互的對象（至少寫給其中一個對象）是不相同的。這在語言中無法得到適當的執行；因此，就處于不安全的領域。

這里的問題比它看起來要復雜得多。如果一個函數的兩個參數都是引用（也就是說，我們沒有在其中改變任何東西），那么就沒有問題。只有當我們有 mutation.const 時，問題才會出現。

Swift 通過使用 copy-on-write 技術來解決這個問題，但這可能會導致效率低下。

Rust 通過跟蹤對象的生命周期來解決這個問題。這給程序員增加了負擔，而且會給程序增加不必要的限制。

可變值語義

函數式編程語言通過禁止突變來避免上述問題。可以對多個對象有多個引用，因為沒有人可以改變這些對象。這對許多程序員來說感覺很不自然，而且對無數的算法來說效率很低。

Val 以一種完全不同的方式解決了這個問題：它對引用增加了限制，并確保沒有人可以讀取一個對象，而其他人卻可以改變它。

Val 認識到整體/部分關系的重要性。這些關系只能形成一棵樹，而不是一個循環圖。如果想修改這棵樹上的一個對象，馬上就能知道這個變化的影響，也就是所有其他可能受到這個突變影響的對象。它允許程序員們推理出哪些對象可以安全地作為讀和寫傳入一個函數。

最后，按照這個邏輯，可以安全地添加引用來表示整體/部分關系。

在 Val 模型中，突變是不被禁止的，但是每次突變一個對象時，編譯器可以計算出哪些對象可以安全地讀取，哪些對象可以同時安全地寫入。安全性可以通過構造來保證。

消除對象之間的任意引用并關注整體/部分關系是賦予 Val 價值語義的原因。但是，由于 Val 也允許值的突變，就可以把這個模型稱為可變值語義學。

科學的方法

走到這一步，作者認為很重要的一個方面：Val 似乎遵循了一種科學的方法。可以看到，在上述內容簡單地描述了一個確保安全的計算模型。這不僅僅是作者提出的關于語言安全的主張。他們有一個安全的證明，在語言的限制下。

該語言的主要創造者 Dimitri Racordon，實際上是一名博士后研究員。Dave Abrahams 似乎也是志同道合的人。Dave 和 Sean Parent 一起重新組建了 Adobe 的 STLabs。可以看出 Alex Stepanov（STL的創造者，也是STLabs的前成員）對 Dave 和 Sean 的研究導向的影響。

不能保證 Val 會像 C++ 那樣成功，但可以發現解決 C++ 的一些基本問題的合理方法：清楚地定義問題，然后提出一個通用而優雅的解決方案。

使用臨時引用

Val 簡單地指出使用臨時引用是不安全的。這使得人們不清楚如何實現需要引用的程序，而不是表達整體/部分關系。

例如，實現一個雙鏈表需要不能被模擬為整體/部分關系的引用。目前還不清楚如何實現具有可變值語義的雙鏈表。另一個例子，考慮一個應用程序中的共享緩存組件。根據定義，這樣的組件需要被多方訪問，并且需要允許突變。同樣，我們也不清楚如何在 Val 中實現這一點。

也許這些例子的簡單答案是，用戶必須將一些代碼標記為不安全。這也許是可以的；作為語言的使用者，我們只是缺乏如何處理這些情況的經驗。Val 必須為處理這些情況提供良好的指導。

C++ 的互操作性

在寫這篇文章的時候，Val 還沒有明確的公開計劃如何來處理與 C++ 的互操作性，它只是宣布了它的意圖。為了成為 C++ 的繼任語言，Val 需要解決這個問題。而且，這個問題似乎并不容易。

首先要注意的是，根據它的描述，Val 的靈感主要來自 Swift。這意味著 Val 和 C++ 之間的差距不小（一邊是 Carbon 和 Cpp2 的差距，另一邊是 C++ 的差距）。縮小這個差距可能需要很大的努力。

第二個障礙是可變值語義系統所帶來的限制。C++ 本質上包含了大量的臨時引用。這意味著，C++ 代碼在 Val 中會被視為包含無數的不安全操作。在作者看來，幾乎所有的 C++ 操作都應該在 Val 中被標記為不安全。這似乎增加了互操作性的差距。

請注意，作者并不是說 Val 不能與 C++ 適當地互操作。只是想表述實現這一點可能不是一個簡單的努力。

4、 Carbon

Carbon 是在 CppNorth 2022 上面世，意欲成為 C++ 繼任語言。Carbon 得到了谷歌的支持（據 Chandler 說，也得到了 Adobe 的支持）。此外，一個有趣的事實是，谷歌則在 CppCon 2022 上缺席；也許這是谷歌在考慮放棄 C++ 的一個標志。

在演講中，Chandler 列舉了目前 C++ 的問題。

大量的技術債務

C++ 優先考慮向后兼容，而不是語言演進；這也阻礙了對技術債務的修復

國際標準化組織的語言發展過程并沒有針對 C++ 發展的實際需求進行優化。

Chandler 認為，解決這些問題的辦法是開始考慮 C++ 的后繼任語言。類似于 C++ 被創造為 C 的繼承者，Swift 被創造為 ObjectiveC 的繼承者，Kotlin 被創造為 Java 的繼承者，則需要找到 C++ 的繼承語言。

為了創建一個 C++ 的繼任語言，需要在現有的生態系統中構建，提供雙向的互操作性，并確保有工具來幫助遷移和學習。而這些實際上就是新宣布的 Carbon 語言的目標。

與 C++ 相比，Carbon 似乎沒有一個標志性的特征。它就像是一個 C++ 的清理項目。在演講中，Chandler 展示了更簡潔的語法、更干凈的指針語義、更好的包裝、更好的公共/私有成員的默認值、顯式參數、繼承清理、API 擴展點和 C++ 0x 風格的泛型。所有這些功能都以這樣或那樣的方式存在于其他編程語言中。

Carbon 可以被看作是具有更好的默認值的 C++，這是件好事。人們會看到一種熟悉的語言更好/更簡單。Carbon 的學習曲線可以很平滑，從 C++ 到 Carbon 的過渡不需要跳過太多的障礙。

但是，另一方面，這與 D 有什么不同？D 也試圖通過學習 C++ 的錯誤和清理其粗糙的邊緣而成為 C++ 的繼承者。是什么讓 Carbon 語言具有內部一致性，而不是讓它感覺像一群不相關的功能？

如果從進化的角度來看，即使今天所有的默認值都很有意義，又有什么能保證它們在接下來的幾十年里都有意義？怎樣才能防止 Carbon 積累技術債務？這個問題的部分答案是，正如 Chandler 提到的，使用工具來協助遷移。但是，都看到了從 Python 2 遷移到 Python 3 是多么的痛苦；可能不是每個人都相信工具可以幫助解決未來的問題。

這些問題都是 Carbon 團隊需要回答的問題。作者表示并不是想說這些問題很難回答，但它們需要被回答。

與 C++ 的互操作性是困難的

即使 Carbon 可以成為一個具有更好的默認值的 C++，與 C++ 的互操作性也不一定容易。下面是 Sean Baxter 提出的一些觀點：

在 Carbon 中沒有功能過載

在 Carbon 中沒有異常處理

在 Carbon 中沒有多重繼承，但人們仍然可以在 C++ 中使用它

與 C++ 不同，Carbon 不處理原始指針

Carbon 沒有構造函數

從這些方面來看，可以很容易地看出，與 C++ 的互操作性將是一個復雜的問題。最有可能的是，即使互操作性問題能夠完全解決，對于大型軟件來說，從 C++ 遷移到 Carbon 也不會是一個簡單的過渡。

文化的興衰

谷歌是一家堅信文化是軟件開發的驅動力的公司。Chandler 在他的主題演講中也用 Peter Drucker 的一句話表達了這一點。

文化把戰略當作早餐，把技術當作午餐，把產品當作晚餐，不久也會把其他一切都吃掉。

雖然企業文化確實是必不可少的，但僅僅引用 Peter Drucker 的話并不是成功的秘訣。主要問題是很難衡量文化及其影響。Chandler 列出了關于 Carbon 文化的幾個要點（包容性、社區友好等）。雖然所有這些觀點都是好的，但它們不足以定義文化，也不足以讓文化在 Carbon 項目中發揮作用。例如，Chandler 沒有提到卓越的技術、毅力、嘗試新事物的勇氣，或者如何優先考慮不同的（與文化有關的）目標。

Lucian Radu Teodorescu 表示在他以前工作的一家公司，有一句口頭禪是 "我們從不讓項目失敗"。谷歌和 Carbon 項目的文化中是否有一個類似的目標？人們似乎把谷歌看作是一家嘗試許多產品并在一段時間后關閉它們的公司。例如，如下圖，Victor Zverovich 的一條推特，他利用這種看法開了一個關于 Carbon 的玩笑。考慮到 Chandler 還宣布谷歌有一個不同的團隊有同樣的目標，但他們從 Rus t開始，轉向 C++ 后，這種思路可能并不太牽強。

Lucian Radu Teodorescu 表示文化是好的，Chandler 提出的觀點也是好的。但是，想要說服一名工程師則需要可驗證的論據。

治理模式

關于 Carbon 公告的一個有趣之處是治理模式。Carbon 項目的目標是實現一種沒有任何公司能決定語言未來的治理。每個人都可以通過創建拉動請求來參與語言的發展，但越是重要的功能，就越需要分析/論證。

對于沒有達成共識的重要功能，有一個由三名成員（Chandler Carruth, Kate Gregory, Richard Smith）組成的指導委員會，負責達成決定。他們沒有機會對設計做出貢獻；他們只需要權衡提交給他們的論據并做出選擇。

有趣的是，這個模型試圖強調一個民主的過程，這在某種程度上類似于 ISO 的目標。這只是對參與各方的不同劃分，當陷入僵局時會有更明確的規則來做什么。如果從事 C++ 標準化工作的人也從事 Carbon 的工作，那么 Carbon 的過程是否會明顯好轉就不清楚了。

雖然民主方法是目前最好的治理方式，但我們最近看到了一系列重大的政治失敗，這些失敗可能與民主的負面影響直接相關。值得一提的是，在古希臘，民主被認為是一種糟糕的治理方式。

5、Cpp2

CppFront 是 Herb Sutter 在 CppCon 2022 的閉幕主題演講中宣布的一個項目。它是一個轉碼器，可以將 "更好的 C++"，即 Cpp2，轉換為舊的 C++。雖然 CppFront / Cpp2 是今年正式宣布的，但 Herb 已經在這個項目上工作了大約 7 年；每年，Herb 都會展示 Cpp2 的一小部分。

Herb 希望改進 C++（即10倍），而不是進行增量式的改變（即10%）。他希望使 C++ 實現 30 年前 Stroustrup 設想的那個更簡單、更干凈的語言的老目標。有趣的是，它采用了 Stroustrup 想改進 C 語言時相同的方法：開始一種新的語言并將代碼翻譯成以前的語言。因此，CppFront 是一個小型轉譯器，它接收 Cpp2 代碼（Herb的新語言）并輸出常規的 C++ 代碼。

Herb 還設定了一些指標，我們可以用這些指標來評估這個實驗是否成功。更安全50倍（也就是減少98%的CVE），更簡單10倍（減少90%的教學指導）。預先定義指標是一個很好的策略，能夠評估實驗的成功；我非常喜歡這個想法。

向后兼容性和互操作性

通過放棄向后兼容性，Cpp2 可以比 C++ 更簡單。這最終允許該語言刪除那些被認為是有害的功能，并重新審視一些被證明是次優的設計選擇。通過放棄向后兼容性，Cpp2 最終可以解決 C++ 中幾十年積累的技術債務。

說實話，在 C++ 中優先考慮向后兼容性優先于語言發展并不是一個可靠的例子。每次我們為語言添加一個主要的功能（例如，概念、程序、模塊等）時，我們實際上是在語言中創造一個新的時代。新的代碼可以與舊的代碼互動，但舊代碼不能簡單地依賴用新特性編寫的新代碼。盡管 C++ 標準沒有正式提及語言時代，但是在語言中有一個底層的時代系統，由新特性的發布所決定。

可以將 Cpp2 看作是 C++ 的一個主要新特性。在互操作性和工具方面，事情要復雜一些，但本質是一樣的。在同一個應用程序中，舊式 C++ 不能與 Cpp2 共存，這在技術上沒有充分的理由。

按照設計，Cpp2 在語義上與 C++ 接近；這使得互操作性更容易。另一方面，這也會阻止 Cpp2 擁有與 C++ 完全不同的特性。例如，Cpp2 就很難使用 C++ 0x 式的泛型。

解決安全問題

安全性提高 50 倍的目標聽起來令人印象深刻。如果 Cpp2 能夠實現這個目標，我相信大多數語言的用戶都會感到高興。

讓我們從這個數字的角度來全面了解其影響。這意味著 98% 的 C++ 應用程序如果被翻譯成 Cpp2 就不會再崩潰了（假設崩潰只由不安全的應用程序產生）。或者說，98% 的 C++ 網絡應用不會有漏洞（如果沒有其他非C++的漏洞）。這將大幅減少崩潰和安全漏洞。

這似乎好得令人難以置信。實際上，如果我們更詳細地分析，這些數字似乎太高了。

首先，如果討論安全問題，需要清楚地知道什么是安全。安全性包括：

類型安全

邊界安全

生命周期安全

初始化安全

對象訪問安全

線程安全

算術安全

Herb 在他的主題演講中提到了上述的前4個項目。然而，這些安全項目的所有方面并沒有得到解決。作為一個主要的例子，在存在原始 pointer 時不能保證生命周期安全；僅僅檢查 pointer 是遠遠不夠的。也沒有任何一個功能來檢測 pointer .null 的使用后刪除情況。

Cpp2，正如 CppCon 主題演講中所描述的，無法檢測到這段代碼的問題：

vec.push_back(vec.front());

Herb 定義了他的安全指標，包括前四個安全組件；故意忽略其他類型的安全似乎很奇怪。尤其是如果被忽略的安全成分很重要的話。

對象訪問安全是指受對象訪問模式影響的安全規則。一般來說，這一類的不安全代碼可以轉化為類型安全、邊界安全或生命周期安全。無效迭代器的規則是這個類別中很好的例子。

線程安全是 C++ 的一個大問題，Herb 完全沒有提到。在她 2021 年的 C++ Now 演講中，Anastasia Kazakova 展示了數據，顯示在 C++ 社區中，并發安全占用戶 setback 的 27%。相比之下，邊界安全問題只占 16%，使用后刪除問題占用戶 setback 的 15%。并發安全是安全性方面最大的痛點，而這一點沒有在 Herb 的列表中得到體現。

Herb 在他的幻燈片上表示，Cpp2 獲得了 "結構安全"。這不可能是真的。結構安全性應該是指語言的構建方式總是能夠導致安全的構造（除非程序員真的忽略了類型系統并將安全性掌握在自己手中）——類似于 Val 或 Rust 的構建方式。但 Cpp2 并沒有這樣做；它只是對一些常見的不安全行為的來源增加了更多的安全檢查。如果你看過 Dave Abrahams 和 Dimitri Racordon 的演講，以及 Sean Parent 的演講，這一點應該馬上就能看出來。

這讓我相信，在安全性上提高 50 倍是不可能實現的目標。

關于目標的可衡量性

理論上，在任何時候，我們都可以根據這些指標來衡量進展，可以評估這個實驗是否成功或能否成功。

讓我們從第二個指標開始：簡單 10 倍，就像我們需要在 C++ 書籍中教授的指導中衡量的那樣。在這個實驗被證明是成功之前，人們不太可能寫關于 Cpp2 的書，但可以想象這樣一本書的內容是什么。可以確定哪些是我們需要教授的關于 Cpp2 的一系列概念，并且我們可以將其與我們目前正在教授的關于 C++ 的內容清單進行比較。因此，我們可以衡量這個指標。

這并不像人們想象的那樣簡單。C++ 有很長的歷史；因此我們知道它的陷阱，人們在 C++ 書籍中記錄了這些陷阱。但是，Cpp2 沒有這么豐富的歷史，所以，人們總是懷疑我們不知道它的所有陷阱。然而，Cpp2 與 C++ 如此接近，我真誠地相信可以排除這些顧慮，得到一個關于簡單性的準確測量。

但是，我不能對第二個指標說同樣的話。我們如何衡量 CVE 和安全漏洞的百分比？首先需要有一個足夠大的 Cpp2 程序的語料庫，由大量的程序員和公司編寫。然而，為了實現這一點，Cpp2 需要被認為是一種成功——一種循環的依賴。因此，在 Herb 的演講中定義的安全度量并不是衡量實驗成功的指標。

在主流語言使用一段時間后，使用這個指標來評估語言是有意義的，但不能判斷實驗的成功。

有還是沒有 monads

在主題演講的1小時33分（以YouTube視頻為參考）中，Herb Sutter 驕傲地說："我沒有說過一次 monads 這個詞"。然后他繼續解釋說，Cpp2 是關于我們目前在 C++ 中使用的語言理念；而不是來自其他語言的奇怪的外來術語。

雖然這句話可能會吸引 C++ 社區中以自我為中心的部分人，但我認為它對社區的傷害要大于幫助。

首先，C++ 到處都在使用 monads。新的 C+ +23 特性可能是使用 monads 的一個已知例子，但 C++ 從根本上說是圍繞著 monads 建立的。當我們調用可能拋出異常的函數時，我們隱含地使用了 monads 。也就是說，幾乎到處都是。

其次，它在語言用戶中創造了一種自給自足的感覺。這樣的聲明不是向社區開放新的想法，而是傳遞了一個信息：C++ 不需要向其他語言學習。但是，該語言擁有的大量技術債務，以及三種繼任語言的出現，證明了這一點。

6、比較

下面的表中試圖提供三種語言之間的比較；C++ 也是一個基準。

今年宣布的 3 種 C++ 繼任語言都被認為是試驗品。并沒有很好的指標表明它們是否真的能成功地吸引足夠數量的編碼人員/代碼庫，在生產環境中使用它們。

看看 GitHub 上的星星數量，我們看到 Carbon 是這群人中的佼佼者，與其他兩個相比，有很大的差距。Carbon 已經成功地在社區內進行了更多的炒作；對包容性的關注和治理模式可能對此有貢獻。

這三種語言也在它們與 C++ 的相似程度方面有所區別。正如所料，Cpp2 是三種語言中最接近 C++ 的。Carbon 似乎離 C++ 更遠，但使用了與 C++ 相同的基本構件塊；在 Carbon 中，用戶的思考方式與他們在 C++ 中的方式基本相同。由于可變值語義，Val 程序員在編程時需要有一個稍微不同的思維模型，這可能使 Val 成為一種離 C++ 更遠的語言。另一方面，如果我們看一下 Val 的快速定義口號，特別是在默認安全和簡單的背景下，該語言的原則似乎可以很好地轉化為 C++ 的受眾。

在這三種新的語言中，Val 是唯一一種能夠支持其安全承諾的語言。其他兩種語言試圖改變一些最不安全的操作的默認值；目前還不清楚這是否有很大的區別。

就語言特性的一致性而言，這三種語言似乎都比 C++ 更好。但在語言的連貫性方面，改變默認值并不能讓你走得那么遠。在這里，與 Carbon 和 Cpp2 相比，Val 的方法似乎更有連貫性。

最后，我認為在我們這樣的工程學科中很重要的一點是：有多少語言設計決定是由某種科學支持的？在這方面，Val 似乎是唯一有一些理論基礎的。這可以為其用戶提供真正的保證。

7、放棄還為時過早

Herb 在他的主題演講中呼吁不要放棄 C++。這是一個來自 C++ 的領導層的證明，人們正在考慮放棄 C++。在一年內出現了三種 C++ 的繼任語言，正好證實了這一想法。C++ 是否開始默默無聞還不得而知，但我們大概可以認為，今年是 C++ 未來的一個拐點。

目前，要判斷這些實驗是否會成功還為時過早。所有的語言都有優點，也都有弱點。如果其中至少有一種成功了，我相信我們會推進編程語言的實踐；這可能意味著在整個軟件行業的積極影響。

在這次比較中，盡可能地保持了客觀，但我確實有自己的偏見。我希望這些偏見不會妨礙在比較這些語言時做得很好。

說到偏見，我確實需要承認：在業余時間，我已經開始與 Val 團隊合作，推動語言的核心理念。對我來說，這些想法，如果能在實踐中得到完善和成功采用，比特定的語言更重要。如果 Val 作為一種編程語言消亡了，但它的所有想法都被納入了 C++，那么我會很高興。

自從我看到 Dave 和 Dimitri 在 C++ Now 上的演講錄音后，我就被可變值語義的思想所吸引。在 2022 年的 CppCon 上，我見到了 Dave 和 Dimitri，并和他們一起探討了一些細節，使我相信 Val 背后的想法是深刻的，經過深思熟慮的，值得密切關注。

看一下流行的數字，Val 的表現并不那么好。可能其中一個原因是，好的想法需要時間來沉淀。套用一個著名的演講，我選擇為 Val 工作，不是因為它容易，而是因為它困難；因為 Val 的目標是值得的。

審核編輯 ：李倩