Google终于开始革C++的命了

微软想通过TypeScript 革了JAVAScript的命

苹果想用Swift革了Objective-C的命

JetBrAIns 想用Kotlin 革了Java的命

现在，google终于要拿C++开刀了。

这个黑色圆圈中的C可不是C语言，而是叫做：

Carbon

为啥Google要搞一个Carbon呢？C++不是Google的五大语言之一吗？

C++，Java，Python/ target=_blank class=infotextkey>Python，JavaScript，Go

长期以来，C++是构建性能关键型应用程序员的主要语言，也积累了大量的项目和类库。

但是C++本身非常复杂，数十年下来，这些项目和类库慢慢变成了技术债务。

C++虽然也在努力发展，但是受到了官僚委员会流程的阻碍，这个流程以标准化而不是设计为导向，添加新功能很困难，一个特别委员会可能需要数年的瀑布流程才能做出重要决定。

可以想象，当Google的人面对着海量C++代码的系统，想改进C++又很难的时候，那种无奈的心情。

既然如此，那就重启炉灶，用碳(Carbon)去燃烧C++吧！

为什么不直接用Rust?

可能很多人有这个疑问，Rust也面向系统级编程，并且被Mozilla设计成内存安全的语言，用来替代C语言。

Google认为，对于新项目来说，用Rust很合适，但是问题在于：

它不像 Java 和 Kotlin 那样具有“双向互操作性”，C++的生态迁移到Rust是很困难的。

而Carbon的目标是C++的后继，是围绕与C++的互操作性以及迁移现有C++代码库而设计的。

不得不说，生态的威力再一次展现，当你想让别人搬家的时候，最好能把他手头的财产一并都搬走，否则每个人都会恋恋不舍。

Carbon的设计目标是这样的：

• 性能要和C++相媲美，要不然就没有吸引力了
• 和C++无缝的，双向的互操作
• 代码应该容易编写、阅读
• 有着实用的安全和测试机制
• 要有一个温和的学习曲线，别把人都吓跑了
• 支持现有的软件设计和架构

开发团队还将着手创建一个内置的包管理器，这几乎是每个语言必备的工具了。

这样，Carbon就可以像TypeScript和Kotlin那样，基于现有C++的生态系统，吸引开发人员，保护现有投资。

看下Carbon的代码吧：

import Console;// Prints the Fibonacci numbers less than `limit`.fn Fibonacci(limit: i64) {  var (a: i64, b: i64) = (0, 1);  while (a < limit) {    Console.Print(a, " ");    let next: i64 = a + b;    a = b;    b = next;  }  Console.Print("n");}

用fn来定义函数，用var 来声明变量，变量类型后置，有Go语言的影子。

用大括号定义函数体和代码块，用分号来分割语句，while 关键字， 有C语言的感觉。

Console.Print(...)，有点C#的味道。

总之，虽然号称是C++的后继，但一点儿也不像C++。

语言特性

我浏览了一下，感兴趣的特性有这些：

指针

指针号称是C语言和C++的精华，可以直接操作内存，强大又灵活。

不过指针也是万恶之源，把指针指向不该指向的地方，程序马上崩溃。

Carbon中也有指针：T* p , 但是为了安全，并不支持指针的算术运算如 p++

Carbon中没有空指针，要指向一个无效的对象，需要使用Optional(T*)

既然有指针，还要和C++互操作，那垃圾收集之类的技术肯定是没法用了，自己小心地管理内存吧。

只提供一种方法来做事情

对于一件事情，Perl语言提供了很多方式来做，在非常灵活的同时也让代码维护者非常困扰。

C++也是这样，例如可以用 "&&" 或者 "and"来表示逻辑运算，可以用struct 和class 来封装数据。可以用0xaa和0xAA表示十六进制。

为了提高代码的可读性和可维护性，促进团队协作，Carbon决定向Python学习：应该只有一种最好的，最明显的方式来做事情。

安全

Carbon 对软件的考量是这样的：

内存安全：不允许越界访问，取消null指针，取消未初始化的指针，禁止访问已经释放的地址

类型安全：不允许用不正确的类型来访问有效的内存

数据竞争安全：防止多个线程在没有“同步”的情况下对内存地址进行读写

其他的特性例如泛型、类.....我这里就不一一赘述了，感兴趣的可以到Github上去看看：
https://github.com/carbon-language/carbon-lang

开发方式

Carbon 是Google内部发起的，但是Carbon团队认为为了未来取得成功，未来需要独立的、开放的社区来主导。

不能像C++委员会那样，虽然保证了国家和公司的代表性，但是限制太多，成本高昂，不出席会议就没有发言权，只有现场人员的投票才能决定。

这和现在的主流开源方式大相径庭，所以Carbon不走“ISO流程”，要拥抱开源，将来由软件基金会和志愿者领导。

一点儿想法

看着Google以及其他国外大厂孜孜不倦地折腾新语言，新系统，不由得联想到国内的大厂，能不能也学学人家，投入资源，做一点儿底层的东西，对IT界做点儿贡献了？别老是在应用层琢磨商业模式了。

我相信，经过20多年的发展，国内绝对有人有能力做类似事情，就看有没有环境去做了。