如何看待許式偉談Go Erlang並發編程差異？

01-20

人家在自己的地盤說點自己的技術觀點而已，不要發展成語言sb大戰好么？

各路大神，有時間去多搞搞基礎知識普及為好。目前的本科及碩士教育，離工程界的要求還差得遠，要我說，多普及一些計算機科學的基礎知識和計算機工程的基本常識，這個對社會的價值大多了。

客觀的講golang的並發機制簡潔，易上手。不過在工業界性能很少成為最主要的難題，每天影響著開發組的，往往不是什麼非同步模型，channel，無鎖演算法之類的玩意兒，而是一些看似很不高大上的問題，就說go的包管理問題吧，真是誰用誰知道，人家rust 1.0版還未發布，包管理已經做的妥妥的

PHP是最好的語言，Python也是。

erlang一直都是走自己的路，一直看好並堅持使用。

看了一遍有瑕疵

我該支持誰呢？

個人覺得，許式偉的這段話完全沒有說服我，或者說還是沒有足以說服人Go的好處。

1. Erlang的進程是個虛擬概念，和輕量級進程不是一回事，我記得LWP的定義好像是要和內核線程1：1的。Erlang進程實際是協程，算是用戶態的線程，Erlang的進程和Go的goroutine都可以看做協程的不同實現。

2. Erlang的調度同樣是基於單線程調度的，一個調度器對應一個線程，但是Erlang是允許配置多調度器多核的。

3. Erlang進程間基本不共享消息，ETS 和 Mnesia 都已幫助用戶實現了互斥，Erlang用戶一般不需要考慮鎖的問題。

4. Go的channel一開始覺得很麻煩，但想想確實還是個不錯的方案，有點像中介者的思想，協程間通信發送方不用管接收方是誰；相比之下，Erlang的mailbox比較傻瓜化，我根本不關心發送順序，按我需要的取出即可。

5. Erlang的IO默認還是同步的，比如文件操作和網路tcp等，不像 NodeJS （IO.js ?）一樣從語言層面就要求你是非同步回調的（因為libev）。

6. 我很喜歡Erlang的Pattern Matching。

7. 聽說Go的release只需要release一個可執行文件，這個很贊。

Erlang目前最大的問題我想應該是好的Erlang程序員難找，這個是現實。道聽途說的一個消息，百度鳳巢那邊原來某系統打算用Erlang寫的，但兩個月後改Golang了，實際就是沒人能夠handle住，畢竟不是每個人都是淘寶yufeng。Golang這點相比入門門檻較低，本身也支持順序編程，所以很多C++系的程序員轉型較迅速。

其實沒有那麼多事，都是工具而已，隨著業界實踐和水平提高語言的演化會有明顯的一同的趨勢，看看現在的很多新語言Rust、Swift等，雖然領域不同，但在一些語言特性上借鑒了多少現代語言的思想。自然選擇淘汰，好的會越好，沒人用的慢慢淡出視野，如此而已。

php是世界上最好的語言！沒有之一！

先聲明，許大牛和余大牛正好都是我崇拜的大牛之二，演講有幸都聽過，微博也都關注，兩人的風格路線略知一二。

兩人都是功夫高手，練的門派卻涇渭分明。

許大牛上來走金山office mfc cpp桌面開發，然後才轉的互聯網應用開發，什麼erlang,golang。語言越來越高級。OO應該理解的無比深入，基礎紮實無比，言必稱編程範式，設計模式。

余大牛走的是系統路線，苦讀linux內核源碼打的基礎。懂得是cpu指令，匯流排，CAS鎖。當然後期也玩高級語言了，愛上了erlang，我覺得大概是erlang的虛擬機採用的是c語言，並且代碼工整設計精巧一如linux內核源碼的緣故。

兩人的實際差別呢，舉個例子，可能不恰當，大牛莫怪，意思意思。

許大牛寫一個Object，可能不加上成員變數的getter,setter就會覺得不符合某種編程範式，渾身不舒服。

而余大牛寫一個if判斷，如果不加上likely,unlikely，則會覺得心裡十分不踏實。

按我個人好惡呢，我是實用主義，一切不以性能為目標的對錯之爭都是耍流氓，哈哈哈

另，七牛做的很好，我很欽佩。

Rust 大法好，Rust 大法保平安

當贊同一個人觀點時，細節錯誤就無視了；

當反對他的觀點時，任何瑕疵都是巨大的靶子。

各位噴爺們。。。噴可以噴，但是能不能就事論事地噴？說說文章的問題，就別提別的了。。。

Erlang為什麼沒有鎖呢？實際上Erlang的伺服器是單進程（Process）的，是邏輯上就無並發的東西。一個Process就是一個執行體，所以Erlang的伺服器和Go的伺服器不一樣，Go的伺服器必然是多進程（goroutine）一起構成一個伺服器的，每個請求一個獨立的進程（goroutine）。但是Erlang不一樣，一個Erlang伺服器是一個單進程的東西，既然是一個單進程的首先所有的並發請求都進入了進程郵箱（後面會談這個進程郵箱），然後這個伺服器從進程郵箱裡面取郵件（請求的內容）然後處理，所以Erlang的單個伺服器並沒有並發的請求，這個是他不需要鎖的根本原因，其實並不是因為它沒有變數，變數不可變這些。因為大家都知道單線程的伺服器一定是沒有鎖的。那麼可能會有人問，那Erlang怎麼做高並發呢？其實是兩點：第一是每個Erlang物理的進程會有很多的伺服器，每個伺服器相互是無干擾的，它們可以並發。第二是單伺服器想要高並發怎麼辦？Erlang對這個問題的回答就是請非同步IO。

呵呵, 我不說什麼了

有一個調查說中國對GAE和GO都是很狂熱的，不知是不是對谷歌過於迷戀了

Go太垃圾了，好處就是簡單，可以讓那些菜雞們體驗下編譯語言，很多人看好Rust，做為一個系統編程語言，和C語言的交互能力一定是一個硬性指標，Rust的FFI做的一點都不好用，Go還C.*** 還在注釋里寫C代碼，不得不說很愚蠢。看D語言與C的交互能力，和C++是一樣的，可以直接互調，而且D語言的語言特性非常豐富，用起來還很輕鬆，不像C++，至於並發模型問題，目前業界普遍認可Erlang的方式，其他語言都是借鑒，也包括D語言

我們團隊認為C++才是最好的，無論是性能還是架構。畢竟更接近彙編語言。我們自研了基於無鎖無等待wait free的任務調度隊列，單CPU每秒調度能力1400萬，雙向2800萬。我們研發了全系列高性能鎖，還有更高性能的hash map等大量全新的C++高並發庫。我們基於自己開發的高性能C++庫開發的KV資料庫，兼容memcache指令集，查詢性能比memcache高64%。軟體下載測試地址http://www.haisql.com/fwzc/soft/。

PPT中，總共糾結了三個問題，非同步IO、message passing、shared 。

對於哪種方式好，哪種不好，很難斷言，各有利弊，只是使用場景不同。所以，沒什麼討論、看待的意義。

只是，對於一個業內大牛來說，總是拿A技術的短處襯托B技術的長處，藉此追捧B技術，達到自己的一些目的，有失風範。

另外，心智問題，唯余呵呵爾。

許大牛erlang根本就沒入門，文章中對erlang的描述氣的令人發抖

就這樣還天天拿erlang出來說事，臉皮也是夠厚