談一點對 go 和 erlang 兩門語言的體會

項目原因用到過ejabberd,所以接觸過erlang,但比較膚淺，無論是理解還是使用。go最近也被炒得比較火，號稱要是一門取代c++和java 的語言。所以，也就順便買了一本許式偉大牛的《go語言編程》，學習了一下。由于這兩門語言，應用的比較多的領域都是網絡編程方面，因此作為使用者，對這 兩門語言寫一點簡單的小體會，做一下比較。

首先表明自己的一個觀點，做為網絡編程，還有構建大型分布式項目而言，如果在這兩門語言之間做選擇，我個人還是傾向于erlang,原因嘛，就目前go的版本和發展階段來講，包括go提供的各種包，都還無法達到otp的水準。后面會具體談一下原因。

go給我印象比較深的幾個特點：

1 對象的defer釋放
2 channel的使用
3 提倡基于消息傳遞而非共享內存的并行編程
4 所謂的協程，當然這不是賣機票的那個攜程

展開闡述一下，第一點，defer這種屬于語法糖性質的小技巧，對于用慣了c或c++的程序員而言，確實是一個非常不錯的體驗，無論程序走什么路徑，都不用擔心資源的釋放了，但這篇還是想從更粗一些的層面來談，就不展開了。

第二點基于channel的讀寫，來控制多線程之間的同步（當然go中叫協程，叫什么不重要），確實很巧妙，其思想也是提倡使用消息傳遞而非使用共享內存 來進行并發編程，這一點和erlang的進程之間的消息傳遞思想是一致的，但感覺沒有erlang用的巧妙，channel只是go中并發同步的一種，在 實際使用中，還是不可避免要用到鎖，所以go還提供了語言包sync.而erlang在這方面而言，則做的比較完備，完全是基于進程間消息傳遞來避免同步 對鎖的競爭。

關于協程的特點，go從幾個方面進行了闡述，一種輕量級線程，系統開銷小，被動式任務調度，不會主動搶時間片等等，其實，真正的實際應用中，令開發者最興 奮的還是其可以無限制的創建上百萬個，而不像操作系統層面的進程和線程那樣，受制于系統資源，比如用c或c++來做并發編程，一般線程數最大也就開到幾百 個，再多的話，受系統資源的限制會比較嚴重。在做性能測試時，我曾嘗試著開過上千個線程，但調度效果，包括因為線程切換帶來的系統開銷非常不理想，除了性 能測試，其他場景不提倡這么干。關于協程的這個特點，我們很容易就會想到erlang中的進程，同樣，erlang中的進程也可以開到上百萬個，除了對 cpu的競爭方式，略有不同外，其實和協程差別不大，而且個人認為比協程用起來要更方便些。

判斷一門語言的優劣，撇開語法不談，人們最關心的還是其框架和庫的強大與否，當然go最為一門新興的語言，其完整的開發包已經達到了130幾個，已經非常 強大，而且日后還會更加完善，這一點也是除了其簡單優雅的語法之外，另一個令人興奮的地方。但是使用下來，和erlang相比，和erlang的otp框 架，和在otp之上構建的各種開源工具比較而言，go在框架方面還是弱了一些。mnesia，rabbitmq等等應用都非常廣，特別是 rabbbitmq已經在業界是公認的做的最完美的消息隊列，可以說沒有之一，只不過由于erlang相對來講，還是小眾了一些，影響了rabbitmq 的推廣和使用。除此之外，erlang在分布式部署方面的優勢是比較明顯的，對常遇到的分布式部署的問題封裝的比較好，節點之間的故障切換，代碼熱替換， 性能觀察，degbug分析，erlang提供的工具相對更便利一些。當然還有其gen_server,gen_event,supervisor，有限 狀態機等行為模式的提供，在快速構建分布式服務這方面，非常強大。

這么說，不是要說要黑哪種語言，而是個人在使用和實踐過程中的一些小體會，同時個人也非常喜歡go。 相對于大家普遍吐槽的erlang函數式編程的語法，go的學習曲線還是比較平緩的，有過c，c++或java或python編程經驗的，上手go會很快，語法都大同小異。而且對于構建大型系統而言，go確實有著相對于傳統的c,c++及java更大的優勢，畢竟可以隨心所欲的創建協程，去干想干的活 兒，而不用考慮系統資源的限制，還是非常爽的。但是，我還是想保留我個人的如下觀點，對于構建大型分布式系統而言，用erlang確實更方便些，這完全是 基于其強大otp框架而言的，開發者只要關心邏輯，實現邏輯即可，其他部署，容災等方面，otp全部都干了，而且干的漂亮。當然go 也同樣可以干的來，而且效率未必比erlang差，還可能更好，只是，需要開發者做的工作，和關心的事情，要更多一些。

來自：程序界