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++ 依然没有成为人们所期望的那种更小、更洁净的言语。它或许仅仅意味着这种更小更洁净的言语仅仅一个空中楼阁。

意欲替代 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++ 的位置之前列出这些言语在需求处理的问题。尽管我的确有一些个人成见，但我会极力客观地进行剖析。”

前期替代者

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++ 程序员经历了突然的搬迁。

Val

Val 给自己的方针定位是:

快速的界说

默许情况下是安全的

简略可与 C++互操作

Val 以这些方针针对 C++、Rust 和 Swift 言语的受众。它的方针是完成 C++ 的功用，但要比 Rust 更简略的办法确保安全。在功用方面，Val 旨在削减编写安全软件所需的方针复制和内存分配的数量。在安全性方面，Val 中的一切结构都确保是安全的，除非用户清晰要求额定的操控（将代码的一部分标记为不安全）。该言语的简略性首要来自于它对 Swift 的激烈影响，通常被以为是一种简略易用的言语。

许多编程言语不一定有一个贯穿其一切功用的中心思维，就像言语的催化剂相同;这会给人的印象是这些言语缺少连接性。这不能说是 Val 的问题。这门言语突出之处在于它有一个模型能够在程序上消除安全问题:它被称为 Mutable Value Semantics（变值语义）。可是，在这之前，一同先来讨论一下它所处理的首要问题。

C++ 实质上是不安全的

这一切都始于这样的观察:在存在骤变的情况下，引证语义或许会导致不安全的程序。由于引证语义答应创立杂乱的依靠联系图，所以骤变不能确保在整个图中保存安全性。例如，假如一个函数对两个方针进行操作并改动了其间一个方针时，就不能确保另一个方针不会以彻底意想不到的办法发生变化。这在单线程和多线程环境中都会产生问题。此外，假如不深化查看一切或许受到影响的代码，程序员们也没有体系的办法来验证骤变的结果。这简直打破了结构化编程的中心思维。

以下面这个 C++ 代码片段为例:

1. voidappend_vec（vector&dest，constvector&src）{for(autox: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++ 恰当地互操作。仅仅想表述完成这一点或许不是一个简略的尽力。

Carbon

Carbon是在 CppNorth2022上面世，意欲成为 C++ 继任言语。Carbon 得到了谷歌的支撑（据 Chandler 说，也得到了 Adobe 的支撑）。此外，一个风趣的事实是，谷歌则在 CppCon2022上缺席;或许这是谷歌在考虑抛弃 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 说到的，运用东西来帮忙搬迁。可是，都看到了从 Python2搬迁到 Python3是多么的痛苦;或许不是每个人都信任东西能够协助处理未来的问题。

这些问题都是 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 的进程是否会明显好转就不清楚了。

尽管民主办法是现在最好的管理办法，但咱们最近看到了一系列严重的政治失败，这些失败或许与民主的负面影响直接相关。值得一提的是，在古希腊，民主被以为是一种糟糕的管理办法。

Cpp2

CppFront 是 Herb Sutter 在 CppCon2022的闭幕主题讲演中宣告的一个项目。它是一个转码器，能够将 “更好的 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 主题讲演中所描绘的，无法检测到这段代码的问题:

1. 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++ 不需求向其他言语学习。可是，该言语具有的很多技能债款，以及三种继任言语的呈现，证明了这一点。

比较

下面的表中企图供给三种言语之间的比较;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 好像是仅有有一些理论根底的。这能够为其用户供给真实的确保。

抛弃还为时过早

Herb 在他的主题讲演中呼吁不要抛弃 C++。这是一个来自 C++ 的领导层的证明，人们正在考虑抛弃 C++。在一年内呈现了三种 C++ 的继任言语，正好证实了这一主意。C++ 是否开端默默无闻还不得而知，但咱们大概能够以为，本年是 C++ 未来的一个拐点。

现在，要判别这些试验是否会成功还为时过早。一切的言语都有长处，也都有弱点。假如其间至少有一种成功了，我信任咱们会推进编程言语的实践;这或许意味着在整个软件行业的积极影响。

在这次比较中，尽或许地坚持了客观，但我的确有自己的成见。我期望这些成见不会阻碍在比较这些言语时做得很好。

说到成见，我的确需求供认:在业余时间，我现已开端与 Val 团队合作，推进言语的中心理念。对我来说，这些主意，假如能在实践中得到完善和成功采用，比特定的言语更重要。假如 Val 作为一种编程言语消亡了，但它的一切主意都被纳入了 C++，那么我会很高兴。

自从我看到 Dave 和 Dimitri 在 C++ Now 上的讲演录音后，我就被可变值语义的思维所招引。在2022年的 CppCon 上，我见到了 Dave 和 Dimitri，并和他们一同讨论了一些细节，使我信任 Val 背面的主意是深入的，经过深思熟虑的，值得亲近重视。

看一下盛行的数字，Val 的表现并不那么好。或许其间一个原因是，好的主意需求时间来沉淀。套用一个闻名的讲演，我选择为 Val 作业，不是由于它简略，而是由于它困难;由于 Val 的方针是值得的。