後端語言選型淺談

前不久回答了一個關於後端語言選型的問題，寫的回答也讓筆者有了不少感觸，所以在這裏談論下本身對後端語言選型的心得體會，姑且算是拋磚引玉，但願你們能分享各自的心得。

後端語言發展歷史

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++ 具備現代化工程開發所須要的各類功能，可是它一樣有缺點：

1. 缺少字符串處理，Web 開發最主要的就是字符串的處理，全部的一切幾乎都要和字符串打交道，可是 C++ 最差的就是字符串處理，只有 std::string 這個標準庫提供的字符串類。用過的基本都知道，這是全部語言中最差的字符串類，缺少方便的 UTF-8 支持，缺少正則表達式匹配，幾乎什麼都缺。

2. 缺少 Web 標準的支持，我這裏說的標準是指語言層面上對 HTTP 協議的支持。Web 是基於 HTTP 協議和 TCP 協議產生的，TCP 協議控制瞭如何傳輸，HTTP 協議定義了瀏覽器和服務端如何通訊。而 C++ 極度缺少這方面的支持，若是須要作非 CGI 開發，只能本身手工處理 Socket 通訊。

3. 缺少 HTTP 框架和業務代碼之間的交互標準，框架就算完成了 HTTP 通訊部分，也沒有一個標準規定框架如何和業務代碼交互。不過，實際上 C++ 框架是實現本身的交互流程。可是缺少規範則是框架稀少的緣由。

這三點主要的缺點很是明顯的，因此社區都沒興趣給寫基於 C++ 的 Web 框架，就算有也是小打小鬧。

Java

Java 的效率相對於 C/C++ 這種手動管理內存的語言來講是低的，哪怕使用了引用計數，C/C++ 也能把 Java 甩出 N 條街。可是 Java 相對於其餘腳本語言來講優點很是明顯

1. 強類型、編譯型語言，這點就使得 Java 在效率遠超動態類型語言，並且在編譯時就能發現 bug，不須要等到運行時再去調試，如今的不少 IDE 也能作靜態語言分析，不須要編譯就能發現語法錯誤，這就能提高效率。

2. Java SE 規範，這就讓 Java 能像 C/C++ 同樣貼近操做系統，自由處理網絡相關、IO 相關的內容，功能很強大。

3. Java EE 規範，完善的規範使得 Java 後端發展有了很好的規範基礎，統一的環境。規範讓框架和業務代碼有了交互的標準（Servlet 脫胎於 Applet，結果 Applet 沒什麼卵用，反而 Servlet 獲得了極大的發展）。

4. Java 有着最完善的生態鏈，不管是框架仍是編譯工具鏈，模塊系統作的很是棒，現代工程所需的各類設計模式都有着很好的實踐。除了 Java 之外，JVM 上面還有着更多的語言能夠選擇。

固然，Java 自己也有不少缺點：

1. 編譯型語言開發效率慢

2. 想要上手開發業務容易，可是想要真正懂得 Servlet 和框架如何運行就難了。

3. 語言自己也存在着不少缺點，好比將 C 那裏繼承過來的類型又從新封裝了一次，一些新穎的技術沒能第一時間引入，好比 Lambda 這樣的到了 1.8 才引入，甚至有人說說，Java 什麼都好，除了語言自己。可是它至少比市面上其餘語言更能接受。

4. 自己的規範和不夠靈活也致使了代碼自己很難優化，好的代碼和差的代碼在一套規則的束縛下實際上性能並無多少差距，更多的優化被交給了 JVM

PHP

PHP 做爲一門腳本語言，自己運行效率確實不是很高，可是在 PHP7 平臺上，已經算是腳本語言中比較高的了，並且在現有的硬件平臺上，PHP 自己的效率基本不會成爲瓶頸。它做爲一門腳本語言也有着不少優點：

1. 天生的模板語言，不須要學習其餘的模板語言，提高了開發效率，也提高了運行效率。（好比 CodeIgniter，就大部分框架來講，使用 PHP 做爲模板語言能提高效率，可是像 Laravel 這種能對模板編譯緩存的另算）

2. 上手容易，生態鏈也很不錯，LAMP、LNMP 這樣部署的技術能夠說是爛大街了，基本沒有學習成本

缺點：

1. 解釋型語言，不能常駐內存，巨大的缺陷。

2. 缺少好用的包管理和命名空間，也缺少好用的模塊系統（Composer 另說）

Node.js

Node.js 做爲目前比較火熱的語言，確實有它的獨到之處，這裏先列舉它的優勢：

1. 事件循環 + 異步 IO，這讓它在高併發的狀況下能大顯身手。

2. JavaScript 易上手，有着活躍的社區和不少的第三方庫

3. 常駐內存簡直不要太好

4. 可用的模塊系統

5. 天生跟 Docker 有緣

6. 前端使用 JavaScript，學習 Node.js 能作到全棧開發

缺點：

1. 也是 JavaScript，JavaScript 是基於原型的語言，從嚴格上來講並無真正面向對象，這樣也讓 JavaScript 在編寫業務代碼的時候極爲困難。

2. 混亂的語言規範，如今並行着 ES五、ES六、ES7，須要 Babel 這樣的工具幫忙

3. 在服務端上只存在 CommonJS 模塊系統，可是在規範上來講則有不少，準確來講這並非一個很大的問題，能夠忽略

4. ES5 愚蠢的回調產生的回調地獄，可是 ES6 解決了這個問題，準確來講也不是什麼大問題。

Swoole

Swoole 跟 Node.js 很類似，相比 Node.js 它在語言層面上比 JavaScript 更加規範好用。可是它存在兩個缺點：

1. 文檔！文檔！文檔！重要的事情說三遍。

2. 單純的 Swoole 擴展基本不能用，必須依賴 Swoole 框架，因此。。。文檔！文檔！文檔！問題仍是文檔

總結

筆者認爲，全部語言實際上都有着它獨到的地方，而關鍵就在於對其認清楚，擇優而爲，選擇正確的工具纔是應有的行爲。