为什么感 觉 C 和 c++ 不火了？

你身边的所有电子设备 内 , 都 是 C 或者 C+ + 写 的 , 会 淘汰 吗，有本事你们 别用电子设备 ， C 语言和 C+ + 在互联网领域热度肯定不 如 Jav a 、 pytho n 、 j s ，我现在做的是工业软件，在工业软件、机器人、自动驾驶、嵌入式等等 工业自动化 相关领域 ， C/C+ + 仍然是绝对的霸主地位。我这里有一套 单片机 物联网资料大全，想自学的小伙伴把 ， 我想白嫖已经三连打在评论区，我给你发 哦 。选择什么编程语言不是根据难易程度，而是生态，比如做工业 软件开发 也可以选 择 Jav a ，毕 竟 Jav a 可以非常简单的调 用 C+ + 的代码 ， androi d 里面应用比较多，但是做工业软件开发一个团队都 是 Jav a ，那底 层 C+ + 算法出问题谁去解决，一个团队编程语言越多扯皮也是越多。

首 先 C 和 C+ + 是两个非常不一样的编程语言 。 C 语言在系统开发领域地位非常稳固，几乎没有替代产品。应用层开发今年来略微有 被 Rus t 取代的迹象 。 C+ + 由于支持的编程范式过多，导致不同水平的人写出来的代码质量差异太大，这给软件的稳健性带来了很大的问题。所以除了对性能有很高要求的系统，一般都会选择其他编程语言 。 Jav a 之所以流行，一部分原因就是它比较死板，不太容易玩出骚操作。招来 的 Jav a 程序员 写出来的代码质量差异不至于太大。

长期来看 ， C+ + 不会被淘汰，但是会变得小众。 说穿了 ， C+ + 只不过 是 C 语言的升级版， 但 C 语言中存在的弊端 在 C+ + 中依旧存在，直到后来， 199 5 年 ， Jav a 被 SU N 公司正式推出 ， Jav a 的一些特性很受程序员们的欢迎，比如再也没 有 C 语言那样的指针，再也不用考虑内存管理，而且还有真正的可移植性，编写一次，到处运行，为了实现跨平台 ， Jav a 中在操作系统和应用程序之间增加了一个抽象层 叫 Java 虚拟机 。 用 Jav a 写的程序都跑在 虚拟机 上，除非个别情况，都不用看到操作系统。

编程语言只是工具

工具的意义在于被使用

c 被发明出来，有其历史的局限性，当时的人，只能做到那个程度

科学技术要发展，就不可能局限在当时那个程度，所以才会有后来 的 c++

以 及 c++++- – ，也就 是 jav a 最开始的名字

当 然 jav a 在诞生之初，有各种问题，但是有问题就去解决问题，并不代表因为它有问题，所以人类科技就不要进步了

这里要特别感谢 苹果 和 谷歌 这种公司，尤其是在 硅谷 的那一干企业，因为正是他们的努力，才使得我们的编程语言越来越简单

比 如 jav a 在一开始就提供了内存自动管理机制，也就 是 g c ，有 了 g c 之后， 内存泄漏 的可能性就大幅下降了，但 是 g c 会有在执行时候整个程序暂停的问题，那怎么办？这是一个问题，就要去解决这个问题，苹果提出 了 ar c ，谷歌提出了 将 hea p 按 照 runne r 切割 ， jav a 自身则在尽一切可能优 化 g c 暂停时间，那到现在，即便是最暴力的缩 短 g c 停顿时间这一维度上，都已经优化到 了 1m s 以内，目前测试结果 是 16 t 的内存，可以 在 1m s 以内完成，而且最大的暂停时间，只有区区 的 0.13ms [1] ，然后这个还在不断优化中，并且在这个科技树上，还进一步衍生出了比如 shenandoah ， lxr [2] 等多种短暂 停 g c 的选择，并且这 些 g c 策略，都由不同的公司完成，比 如 shenandoa h 主要 有 red ha t 红帽完成， 而 lx r 则是 由 Googl e 的人完成，这进一步促进了这个领域的繁荣和发展

那 g c 都能被优化 到 1m s 以内，还有几个软件不能接受这个时长的暂停呢？

作为参照和对比，人的反应时间 是 0. 2 秒，也就 是 200m s 以上，经过训练的运动员，可以达 到 0.1 s 也就 是 100m s ，再低就不太可能了，然后人的眼睛，对于动画的敏感度，大概 在 6 0 帧左右，也就 是 1/6 0 ，大约 是 16-17m s 之间这样子，所以低 于 1m s 的暂停，人是感觉不到的，你感觉得到的话应该去国家安全机构应聘，因为国家需要你这种超能力者

这是一方面

另外一方面 ， c+ + 对 于 c 的兼容性，在早期也是一个优势，就比如你 用 c+ + ，调 用 c 写的类库，比较简单，相比之下， 用 jav a 的 jn i ，就很麻烦， 那 jn i 就是 ffi 的一种，所 谓 ff i ，就是调用其他语言 的 ap i 的这么一个功能

比如你 用 jav a ，要调 用 c 写的 类库 ， dll/so/dyli b 这种，就非常麻烦 ， jn i 用起来，既要 懂 c ，又要 懂 jav a ，那这个就明显阻碍了普通用户的使用

那 ff i 这一块这些年也是发展迅速，改善明显，现在普遍能够实现的就是，让用户不需要 碰 c 等代码，通过工具，可以自动生成对应的语言接口，这样就可以让用户在不 懂 c 的前提下，也能调 用 c 编写 的 ap i ， 那 nativ e 部分语言，大部分都提供了 跟 c 兼容的方式，比如 说 swif t 的 @_ cdecl ，那通 过 c ，就可以将大部分语言连接起来，而且不需要用户了 解 c 的知识，也能够将其利用

那这个就很方便了，就会出现一种情况，就是，我不需要知道你是怎么做的，我也不需要懂你所用的知识，但是这都不妨碍我使用你的劳动成果

ff i 领域这些年的发展，主要就是要达成这个目标

这一块不管是苹果还是谷歌，都有自身相应产品，比如上文说 的 swif t 的 @_cdce l ， swif t 没 有 g c ，所以 跟 c 兼容起来比较容易， 那 flutte r 和 jav a 这种，需要的工作量就大一点，因 为 c 没 有 g c ，所 以 c 画出来的内存，你是不是也要将其纳 入 g c 扫描的范畴之内呀？你看，这里就有很多工作要做

但是经过七八年的发展，也基本上接近完工了，相关文档，直接看官方文档就行了 ， jav a 的内容多一点，那有 了 ff i 之后，你对 有 g c 的软件性能不满意，你完全可以自己动手， 用 nativ e 语言实现一个，然后嫁接到你的代码中去

然后是第三个发展方向，就是将带 有 g c 的语言编写出来的软件自身，编译 成 native

之 前 jav a 等语言， 跟 c 等 nativ e 语言，一个实质性的差别就是编译产物 ， jav a 编译成字节码，然后在执行时候，再将 字节码 翻译成机器码执行， 而 c ， c+ + 语言则是直接编译成机器码

那除了字节码以外，还有其他的中间码，比 如 llv m 用的 bitcode ，当然原因不是为了跨平台，而是为了复用编译器后端，为动态类型和静态类型语言提供一个统一的编译器后端

那因为在这些代码执行的时候，多了编译成 机器码 这一步，所以启动时候相对较慢，而且运行时也相对大一点，因为多了一步工作嘛，那这个在某些场景下，就会降低用户的体验

所以将源码编译成机器码的需求，其实是存在的

那最早开始对这一块动手的，还就是谷歌，的安卓，因为客户 端 ap p 对这些性能比较敏感，你下载一 个 ap p ，又大又慢，用户肯定会有意见，早些年的安卓，被诟病说，不 如 io s 流畅，就是因 为 jv m 变 种 dalvi k 的缘故，时至今日，苹果在介 绍 swif t 的时候，还在畅 谈 ao t 和 ji t 对比下， aot 的好处

所 谓 ao t 就是将源码编译成机器码， 而 ji t 就是传 统 jav a 那种方式，先编译成字节码，然后在运行时再编译成机器码再执行

那既然苹果和谷歌都认为 ， ao t 有好处，那这里就有需求存在，所以安卓后来就制作出 了 ar t ， android runtim e ，安卓运行时，就是 把 ap p 直接编译成机器码，就 是 aot

随后诞生 的 flutte r ，也同时提供 了 ji t 和 ao t 两种编译选项，允许用户在测试时候，使 用 ji t 编译，编译执行，并 在 ap p 发布的时候，使 用 ao t 编译，编译成机器码，以给终端用户更好的使用体验

随 后 jav a 又提供 了 graa l 等项目，实现 了 ao t ，时至今日 ， jav a 也已经表态，要制 作 project leyde n ，也就是正式 的 ao t 功能

这一块是将来大概十年左右时间的发展重点， 那 jav a 等语言能够同时提 供 ji t 和 ao t 两种选择，那相比之下 ， c/c+ + 只 能 ao t ，不 能 ji t ，那自然受众就要小一点了

其他还有一些功能性上的特性，比如值类型，可以连续内存，在软件吃特别大内存时候，这些特性可以帮助节省内存，还有虚拟线程等等，不一一列举

但是总得说来，这些年，编程语言发展方向是朝着开发越来越简单，对用户要求越来越低的方向上去在发展

过去，我们需要一个程序员懂指针，懂得回收内存垃圾，懂各种古里古怪的语法，还有各种知识

但是随着科学技术的发展，我们越来越不需要一个程序员什么都懂，你不懂也没关系，不妨碍我们实现我们的目的就好了

随着科学技术的发展和进步，编程手段会越来越丰富，越来越简单，越来越规范

这或许能回答你的问题，为什么不火了，因为现在你有更加简单的手段去实现你的目的