微软想通过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多年的发展，国内绝对有人有能力做类似事情，就看有没有环境去做了。
