淺談WEB后端語言的選型

　前不久回答了一個關于后端語言選型的問題，寫的回答也讓筆者有了很多感觸，因此在這里談論下自己對后端語言選型的心得體會，姑且算是拋磚引玉，希望大家能分享各自的心得。
　　后端語言發(fā)展歷史
　　Web 后端語言的興起是從靜態(tài)網頁向動態(tài)網頁的發(fā)展所產生的，最早的動態(tài)頁面技術就是 CGI 技術，將客戶端的輸入交給 CGI 程序，然后將 CGI 程序的輸出返回給客戶端。早期的 CGI 程序只要是任何有標準輸入輸出的語言都可以編寫，這也就是第一代后端平臺。
　　后來為了簡化 CGI 程序的修改編譯發(fā)布的流程，就有了腳本語言實現 CGI 應用。也就是 Perl 這樣的語言。也就是第二代后端平臺。雖然 Perl 作為腳本語言解決了開發(fā)效率的問題，但是它同樣需要在程序代碼中摻雜 HTML 語言，為了解決這個問題，就有了 PHP 這樣的將 HTML 和 程序代碼混雜，并且能快速開發(fā)的語言。同時，Java EE 的標準也提出了 JSP 這樣的解決方案，也就是第三代后端平臺，從此，現代的后端開發(fā)基本就形成了。再往后來，也就是 Node.js Go Swoole 這種以事件循環(huán)、常駐內存為特點的后端平臺，姑且能算是第四代后端平臺。而目前來說，第三代和第四代開發(fā)平臺是并存的。
　　語言優(yōu)缺點
　　C/C++
　　C 語言雖然是非常貼近操作系統的語言，能和操作系統 API 很好的交互，但是 C 語言并沒有現代化工程開發(fā)所需要的面向對象功能，當然也缺乏泛型之類的功能，如果以 CGI 的形式開發(fā)，那么缺點非常明顯，這也是第二代后端平臺興起的原因。
　　C++ 具有現代化工程開發(fā)所需要的各種功能，但是它同樣有缺點：
　　缺乏字符串處理，Web 開發(fā)最主要的就是字符串的處理，所有的一切幾乎都要和字符串打交道，但是 C++ 最差的就是字符串處理，只有 std：：string 這個標準庫提供的字符串類。用過的基本都知道，這是所有語言中最差的字符串類，缺乏方便的 UTF-8 支持，缺乏正則表達式匹配，幾乎什么都缺。
　　缺乏 Web 標準的支持，我這里說的標準是指語言層面上對 HTTP 協議的支持。Web 是基于 HTTP 協議和 TCP 協議產生的，TCP 協議控制了如何傳輸，HTTP 協議定義了瀏覽器和服務端如何通信。而 C++ 極度缺乏這方面的支持，如果需要做非 CGI 開發(fā)，只能自己手工處理 Socket 通信。
　　缺乏 HTTP 框架和業(yè)務代碼之間的交互標準，框架就算完成了 HTTP 通信部分，也沒有一個標準規(guī)定框架如何和業(yè)務代碼交互。不過，實際上 C++ 框架是實現自己的交互流程。但是缺乏規(guī)范則是框架稀少的原因。
　　這三點主要的缺點非常明顯的，所以社區(qū)都沒興趣給寫基于 C++ 的 Web 框架，就算有也是小打小鬧。
　　Java
　　Java 的效率相對于 C/C++ 這種手動管理內存的語言來說是低的，哪怕使用了引用計數，C/C++ 也能把 Java 甩出 N 條街。但是 Java 相對于其他腳本語言來說優(yōu)勢非常明顯
　　強類型、編譯型語言，這點就使得 Java 在效率遠超動態(tài)類型語言，而且在編譯時就能發(fā)現 bug，不需要等到運行時再去調試，現在的很多 IDE 也能做靜態(tài)語言分析，不需要編譯就能發(fā)現語法錯誤，這就能提升效率。
　　Java SE 規(guī)范，這就讓 Java 能像 C/C++ 一樣貼近操作系統，自由處理網絡相關、IO 相關的內容，功能很強大。
　　Java EE 規(guī)范，完善的規(guī)范使得 Java 后端發(fā)展有了很好的規(guī)范基礎，統一的環(huán)境。規(guī)范讓框架和業(yè)務代碼有了交互的標準（Servlet 脫胎于 Applet，結果 Applet 沒什么卵用，反而 Servlet 得到了極大的發(fā)展）。
　　Java 有著最完善的生態(tài)鏈，無論是框架還是編譯工具鏈，模塊系統做的非常棒，現代工程所需的各種設計模式都有著很好的實踐。除了 Java 以外，JVM 上面還有著更多的語言可以選擇。
　　當然，Java 本身也有很多缺點：
　　編譯型語言開發(fā)效率慢
　　想要上手開發(fā)業(yè)務容易，但是想要真正懂得 Servlet 和框架如何運行就難了。
　　語言本身也存在著很多缺點，比如將 C 那里繼承過來的類型又重新封裝了一次，一些新穎的技術沒能第一時間引入，比如 Lambda 這樣的到了 1.8 才引入，甚至有人說說，Java 什么都好，除了語言本身。但是它至少比市面上其他語言更能接受。
　　本身的規(guī)范和不夠靈活也導致了代碼本身很難優(yōu)化，好的代碼和差的代碼在一套規(guī)則的束縛下實際上性能并沒有多少差距，更多的優(yōu)化被交給了 JVM
　　PHP
　　PHP 作為一門腳本語言，本身運行效率確實不是很高，但是在 PHP7 平臺上，已經算是腳本語言中比較高的了，而且在現有的硬件平臺上，PHP 本身的效率基本不會成為瓶頸。它作為一門腳本語言也有著很多優(yōu)勢：
　　天生的模板語言，不需要學習其他的模板語言，提升了開發(fā)效率，也提升了運行效率。（比如 CodeIgniter，就大部分框架來說，使用 PHP 作為模板語言能提升效率，但是像 Laravel 這種能對模板編譯緩存的另算）
　　上手容易，生態(tài)鏈也很不錯，LAMP、LNMP 這樣部署的技術可以說是爛大街了，基本沒有學習成本
　　缺點：
　　解釋型語言，不能常駐內存，巨大的缺陷。
　　缺乏好用的包管理和命名空間，也缺乏好用的模塊系統（Composer 另說）
　　Node.js
　　Node.js 作為目前比較火熱的語言，確實有它的獨到之處，這里先列舉它的優(yōu)點：
　　事件循環(huán) + 異步 IO，這讓它在高并發(fā)的情況下能大顯身手。
　　Java 易上手，有著活躍的社區(qū)和很多的第三方庫
　　常駐內存簡直不要太好
　　可用的模塊系統
　　天生跟 Docker 有緣
　　前端使用 Java，學習 Node.js 能做到全棧開發(fā)
　　缺點：
　　也是 Java，Java 是基于原型的語言，從嚴格上來說并沒有真正面向對象，這樣也讓 Java 在編寫業(yè)務代碼的時候極為困難。
　　混亂的語言規(guī)范，現在并行著 ES5、ES6、ES7，需要 Babel 這樣的工具幫忙
　　在服務端上只存在 CommonJS 模塊系統，但是在規(guī)范上來說則有很多，準確來說這并不是一個很大的問題，可以忽略
　　ES5 愚蠢的回調產生的回調地獄，但是 ES6 解決了這個問題，準確來說也不是什么大問題。
　　Swoole
　　Swoole 跟 Node.js 很相似，相比 Node.js 它在語言層面上比 Java 更加規(guī)范好用。但是它存在兩個缺點：
　　文檔！文檔！文檔！重要的事情說三遍。
　　單純的 Swoole 擴展基本不能用，必須依賴 Swoole 框架，所以。。。文檔！文檔！文檔！問題還是文檔
?