Linux之父Linus Torvalds曾经在三年前，因为微软的一位同学质疑Git用C语言开发，而将C++痛批了一顿。当时，他是这样评论的：
C++正处在困境当中，它既无助于简化，以实际用于进行原型化或者简单的GUI编程，又不是像C那样的简洁的系统编程语言，能够积极地鼓励你使用简单和直接的语言构造。
2010年6月5日到11日，他又在邮件列表中连续发贴，直截了当地炮轰C++。他明确表示：“我确实不喜欢C++，依我来看，它真的是一门很烂的语言。”
他还说，C++语言想解决的问题都不对路，都是一些皮毛问题，而没有涉及真正深层次的问题。C++的对象、模板和函数重载都基本上纯粹是C的语法扩展，是语法糖，总体上把C的语法和类型系统都弄得更糟。他建议，在系统编程里直接用C就可以，非系统编程里，应该选择一种有垃圾收集的语言，C++语言的特性基本无用，只会捣乱。因此，什么时候C++都不可能是正确的选择。
在另一个帖子中，他进一步说明，内核开发使用C语言而非C++的理由之一，是交流。在庞大的项目中，人们对不是自己开发的模块并不了解，能快速理解其他模块中函数的确切含义才能提高开发效率。而C++引入的各种抽象则使代码非常依赖上下文，想理解一段代码，需要看多得多的上下文。对于需要不断打补丁(小段代码)的内核来说，这是非常要命的。Linus也承认，在其他一些情况下，可能需要更多语言支持，语言级的内存分配机制如垃圾收集、并发、动态代码生成等等。但是内核开发不需要。而且，即使是这些方面，C++也不灵。他不忘嘲笑C++的new关键字很蠢。
有人问到，C++没有解决的深层次问题是什么?Linus回答，比如并发。他进而又痛批了一通：C++是狗屎，根本没啥设计，只是在C上面加了些渣滓而已。
有人问Linus对Go语言怎么看。他回答，Go语言里有些不错而且重要的东西值得关注，许多决策都很合理。但设计者自己称这个语言为实验性的，这当然有其原因。而且，引入一种新语言没那么容易，过二十年再说吧。
此外，Linus还在另一个帖子里痛批了面向对象语言。他认为面向对象语言以对象为核心，加一些相关联的方法，简直是呓语。重要的东西应该是数据结构，对象本身有啥重要?真正有意思的，是在不同类型的不同对象交互而且有锁规则的时候。但是，即使是这时候，封装什么“对象接口”也绝对错误，因为不再是单一对象的问题了。他的结论是，面向对象解决的都是一些小问题。
网易的云风为此撰写了一篇博客，其中谈到：
我想说，C 的三个特质(见引用文最后一段) 哪一点都不可忽略。Linus 这次强调的大约是第三点(即交流——编者注)，也是 C++ 程序员们不屑一顾的一点。可对于多人协作构建的项目，这一点实在是太重要了。这并不是人人都聪明就能回避的问题。如果程序员们都足够睿智，反而更能意识到沟通之成本。其实即使是你一个人在做整个项目，从前的你和现在的你以及将来的你，同样有沟通(记忆)的成本。人不可能两次踏进同一条河流。
不过，他似乎只读了Linus谈交流的那篇帖子，所以得出了这次Linus比较平和的结论。呵呵，哪里平和，
简直是全盘否定啊。
Linux内核创始人Linus Torvalds说使用C语言而非C++的理由
[日期：2010-06-15]来源：cnbeta 作者：cnbeta[字体：大 中 小]
Linux内核的创始人Linus Torvalds最 近在一封邮件中说明了内核开发需要使用C语言而非C++的理由。
Name: Linus Torvalds ([email protected]) 6/8/10
anon2 ([email protected]) on 6/8/10 写道:
>
>效率对于内核的开发是个至关重要的问题。
>大部分志愿者为内核贡献代码，所以在相
>同条件下，使用更高效的语言能让你的工
>作效率提升，从而更快更出色的完成开发。
事实上，你错了
志愿者贡献的代码很优秀，而且他们似乎没有觉得语言的效率是个障碍。如果改换语言真的能提高效率，那么这将是使大众受益的事情——不仅仅是经济方面 的。一行行的写代码，而不和用户交流，即使使用再有效率的语言都是无用的，很多大型项目都有这个问题的。
内核方面，我们有大约1000个志愿者者为每一个内核的释出做着贡献（3个月前统计的结果）。现在有更多的人加入，但是我更为担心的不是代码，而是 编码方面的持续性和linux内核的发展方向。现在，我已不写代码很多年。我目前主管志愿者的代码是否进入内核，如果代码可以进入内核，我就说ok，进去 吧；如果不能，我就说No——当然这种情况比较少。
如果想做好一个产品，最重要的就是要与客户进行交流。内核的编写也是如此，缺乏交流是整个项目的瓶颈……避免交流缺失最好的办法就是拥有共同的 “culture”（信仰吧……），或者拥有共同的默契感（原文：潜规则，汗之～）。我们有很多文档指导人们如何去做以及怎样去做，但是在不同文化背景的 人们面前，这些文档是那么苍白无力……
（有很多书在介绍文化，你甚至可以在大学取得一个相关的PhD学位，然后穷极一生去学习，但是，但是你却从来没有深入了解过自己……）
c语言呢，也有自己的“文化”（Unix也是如此——让我想起了KISS）。一个语言，就应该简单而明确，而不是复杂冗余。c++有一个绝对让我不 爽的“特性”—— context-dependent，这只是意味着， 当你阅读代码时，本地视图（local view）却不能给你任何帮助。
这，在交流上可是个大问题……在庞大的项目中，人们对不是自己开发的模块并不了解，能快速理解其他模块中函数的确切含义才能提高开发效率，而C++ 引入的各种抽象则使代码变得晦涩难读。
如果你想提交代码（或者补丁），是不是感觉 “sctp_connect()” 比 “connect()” 简洁而且明了呢？（匈牙利命名？） ，剩下的交给编译器吧，编译器能知道你写的是sctp协议模块的，并完成一切。
项目开发中，我们尽量使用补丁和分支，邮件列表等形式，而不是对源码进行整体修改，这是因为唯一重要的在于改变，而不是结果。所以，这也是我们避免 歧义和代码关联性（context）的根本原因。——尤其是在内核项目上，绝对不能有半点马虎。绝大多数软件工程上都是如此，其实在日常交往中也应该如 此：说话含糊不正常的得不到好处。
因此，一个语言应该简单而明确。你不必顾虑过多，也不用学习冗长的语法和你不需要的东西。如果每个人都是项目专家，那么隐含方式调用函数 （implicit context）是个不错的主意——这就是为什么真正深奥的科学文献，基本上都是晦涩难懂的，除非你是一个专家，拥有大量的背景知识以及要素，才能有所了 解。但是如果是一个多人参与的大型项目，呃，这几乎是不可能的。
例如，我非常了解 VM 部分的代码，但我仍然需要读取各文件系统和网络的代码。即使像我这样了解的人，仍然把代码写的简明扼要，绝不会有任何“隐藏代码”。c就是这样一个语言， 读代码，就能知道它的作用。一个函数用来做一件事，而这个函数也只作这一件事情，不会再出现一些“微妙的问题”——这是“哪个版本的一个函数调用”。
这也就是为什么我认为c语言“简约而不简单”——尤其是对于一个os的内核来说，尤为重要；在特定的编程或系统亦是如此。这也是为什么我不认为在所 有项目中c都适合的原因。
不过，c++……我真得不认为它有什么出色的地方。垃圾回收和并发等等，这些才是真正重要的特性。可是c++……完全落在了c后边……