C语言是C++的子集，C++也支持面向过程的编程，这似乎这就意味着C++已经包括C语言了吧，那么为什么还要独立的C语言？
说个实现上的原因。
C本身相对简单，各种操作系统都能设立自己的统一CABI。
而C++的ABI要求比C复杂很多，以至于各大编译器提供者有长久的分歧，同系列编译器的不同版本间不时也出现分歧。
1.新写的操作系统，要在上面搭建一个开发环境套件，首先考虑移植上去的语言几乎一定是C。
2.提供的用户态接口基本也是C的。无它，容易，而且你C++不是兼容C嘛，我干嘛要提供C++接口来抛弃C程序员呢（类似很多windows应用程序坚持只提供x86而不提供x64版本一样）。
3.操作系统动态库的某些API对C支持较为方便，让C几乎成了动态库的标准接口语言。
4.其他语言也选择动态库来和其他语言交互，因为3，不得不也对C和他的ABI产生一些依赖。
5.综上，从操作系统到其他非C/C++语言，整个软件生态体系都对C语言有依赖，C++何以言取代之？Objectivec++还兼容C++呢，除了从事特殊底层开发的，有几个人用过？
C++编译器实现太复杂，很多嵌入式平台都只支持C（如很多DSP芯片）。就算支持C++，往往也不是所有特性都支持，最典型的就是异常和RTTI（这个主要是为了减少二进制文件体积以及运行时占用的内存的大小，因为这些功能在DSP上几乎用不到）。
分几个层次去看待：
主要问题是语言复杂度太高，使得人书写难度变大，变相阻碍了语言发展。
表面问题是runtime，C功能更精简，底层提供一个runtime以及配套的编译器更方便。LLVM的出现理论上应该大大降低了这一门槛，但现实是C++依旧没多大起色，所以我觉得这个只是表面的问题。
虚假问题是ABI。诚然C++没有统一的ABI，但这不妨碍一个组件用C++编写并提供纯C的接口（虽然这也会失去C++的许多功能优势，但换个角度，哪个用纯C接口的库能带上自己语言的花式特性的啊？）。
事实上，我觉得除了底层受限的情况（如内核、嵌入式开发、资源稀缺，或者是不想依赖C++runtime），任何新项目都不应该用C去写。
C++特性是多是复杂，但本身并不要求你使用全部特性。
用constexpr代替部分宏不好吗？用模板代替部分宏不好吗？
还有各种有利于开发维护的特性。
那些说C编译出的二进制结果确定的还是醒醒吧，难道你编译C不开优化的吗？想要精确控制就上汇编，C的语言规范里有说保证编译结果与代码一一对应吗……
归根到底，C++太复杂了，复杂到用户还没学就被吓跑了，复杂到C用户没法低成本享受高方便。
完全取代是一定不可能的，但没能成功地大量侵占C的地盘，这还是得赖C++自己。
超实用性的Python零基础入门到进阶视频源码淘宝￥2购买已下架