后端语言选型浅谈
前不久回答了一个关于后端语言选型的问题，写的回答也让笔者有了很多感触，因此在这里谈论下自己对后端语言选型的心得体会，姑且算是抛砖引玉，希望大家能分享各自的心得。
后端语言发展历史
Web 后端语言的兴起是从静态网页向动态网页的发展所产生的，最早的动态页面技术就是 CGI 技术，将客户端的输入交给 CGI 程序，然后将 CGI 程序的输出返回给客户端。早期的 CGI 程序只要是任何有标准输入输出的语言都可以编写，这也就是第一代后端平台。
后来为了简化 CGI 程序的修改编译发布的流程，就有了脚本语言实现 CGI 应用。也就是 Perl 这样的语言。也就是第二代后端平台。虽然 Perl 作为脚本语言解决了开发效率的问题，但是它同样需要在程序代码中掺杂 HTML 语言，为了解决这个问题，就有了 PHP 这样的将 HTML 和 程序代码混杂，并且能快速开发的语言。同时，Java EE 的标准也提出了 JSP 这样的解决方案，也就是第三代后端平台，从此，现代的后端开发基本就形成了。再往后来，也就是 Node.js Go Swoole 这种以事件循环、常驻内存为特点的后端平台，姑且能算是第四代后端平台。而目前来说，第三代和第四代开发平台是并存的。
语言优缺点
C/C++
C 语言虽然是非常贴近操作系统的语言，能和操作系统 API 很好的交互，但是 C 语言并没有现代化工程开发所需要的面向对象功能，当然也缺乏泛型之类的功能，如果以 CGI 的形式开发，那么缺点非常明显，这也是第二代后端平台兴起的原因。
C++ 具有现代化工程开发所需要的各种功能，但是它同样有缺点：
缺乏字符串处理，Web 开发最主要的就是字符串的处理，所有的一切几乎都要和字符串打交道，但是 C++ 最差的就是字符串处理，只有 std::string 这个标准库提供的字符串类。用过的基本都知道，这是所有语言中最差的字符串类，缺乏方便的 UTF-8 支持，缺乏正则表达式匹配，几乎什么都缺。
缺乏 Web 标准的支持，我这里说的标准是指语言层面上对 HTTP 协议的支持。Web 是基于 HTTP 协议和 TCP 协议产生的，TCP 协议控制了如何传输，HTTP 协议定义了浏览器和服务端如何通信。而 C++ 极度缺乏这方面的支持，如果需要做非 CGI 开发，只能自己手工处理 Socket 通信。
缺乏 HTTP 框架和业务代码之间的交互标准，框架就算完成了 HTTP 通信部分，也没有一个标准规定框架如何和业务代码交互。不过，实际上 C++ 框架是实现自己的交互流程。但是缺乏规范则是框架稀少的原因。
这三点主要的缺点非常明显的，所以社区都没兴趣给写基于 C++ 的 Web 框架，就算有也是小打小闹。
Java
Java 的效率相对于 C/C++ 这种手动管理内存的语言来说是低的，哪怕使用了引用计数，C/C++ 也能把 Java 甩出 N 条街。但是 Java 相对于其他脚本语言来说优势非常明显
强类型、编译型语言，这点就使得 Java 在效率远超动态类型语言，而且在编译时就能发现 bug，不需要等到运行时再去调试，现在的很多 IDE 也能做静态语言分析，不需要编译就能发现语法错误，这就能提升效率。
Java SE 规范，这就让 Java 能像 C/C++ 一样贴近操作系统，自由处理网络相关、IO 相关的内容，功能很强大。
Java EE 规范，完善的规范使得 Java 后端发展有了很好的规范基础，统一的环境。规范让框架和业务代码有了交互的标准（Servlet 脱胎于 Applet，结果 Applet 没什么卵用，反而 Servlet 得到了极大的发展）。
Java 有着最完善的生态链，无论是框架还是编译工具链，模块系统做的非常棒，现代工程所需的各种设计模式都有着很好的实践。除了 Java 以外，JVM 上面还有着更多的语言可以选择。
当然，Java 本身也有很多缺点：
编译型语言开发效率慢
想要上手开发业务容易，但是想要真正懂得 Servlet 和框架如何运行就难了。
语言本身也存在着很多缺点，比如将 C 那里继承过来的类型又重新封装了一次，一些新颖的技术没能第一时间引入，比如 Lambda 这样的到了 1.8 才引入，甚至有人说说，Java 什么都好，除了语言本身。但是它至少比市面上其他语言更能接受。
PHP
PHP 作为一门脚本语言，本身运行效率确实不是很高，但是在 PHP7 平台上，已经算是脚本语言中比较高的了，而且在现有的硬件平台上，PHP 本身的效率基本不会成为瓶颈。它作为一门脚本语言也有着很多优势：
天生的模板语言，不需要学习其他的模板语言，提升了开发效率，也提升了运行效率。（比如 CodeIgniter，就大部分框架来说，使用 PHP 作为模板语言能提升效率，但是像 Laravel 这种能对模板编译缓存的另算）
上手容易，生态链也很不错，LAMP、LNMP 这样部署的技术可以说是烂大街了，基本没有学习成本
缺点：
解释型语言，不能常驻内存，巨大的缺陷。
缺乏好用的包管理和命名空间，也缺乏好用的模块系统（Composer 另说）
Node.js
Node.js 作为目前比较火热的语言，确实有它的独到之处，这里先列举它的优点：
事件循环 + 异步 IO，这让它在高并发的情况下能大显身手。
JavaScript 易上手，有着活跃的社区和很多的第三方库
常驻内存简直不要太好
可用的模块系统
天生跟 Docker 有缘
前端使用 JavaScript，学习 Node.js 能做到全栈开发
缺点：
也是 JavaScript，JavaScript 是基于原型的语言，从严格上来说并没有真正面向对象，这样也让 JavaScript 在编写业务代码的时候极为困难。
混乱的语言规范，现在并行着 ES5、ES6、ES7，需要 Babel 这样的工具帮忙
在服务端上只存在 CommonJS 模块系统，但是在规范上来说则有很多，准确来说这并不是一个很大的问题，可以忽略
ES5 愚蠢的回调产生的回调地狱，但是 ES6 解决了这个问题，准确来说也不是什么大问题。
Swoole
Swoole 跟 Node.js 很相似，相比 Node.js 它在语言层面上比 JavaScript 更加规范好用。但是它存在两个缺点：
文档！文档！文档！重要的事情说三遍。
单纯的 Swoole 扩展基本不能用，必须依赖 Swoole 框架，所以。。。文档！文档！文档！问题还是文档
总结
笔者认为，所有语言实际上都有着它独到的地方，而关键就在于对其认清楚，择优而为，选择正确的工具才是应有的行为。
关键字：node.js, php, java, 语言
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！