為啥 Erlang 沒有像 Go、Scala 語言那樣崛起？
曾經非常看好。
先說明一下，這裡所說的崛起是指有成熟的殺手級產品，技術棧完整，社區活躍，會的懂的人比較多。scala 目前業界應用廣泛，技術棧完整，社區活躍，還有 spark 這個重量級殺手鐧；go 類似，也有 docker；erlang 呢？不是在黑 erlang，只是想從各方面分析一下 erlang 沒流行起來的原因，不管是從語言特性還是從成本，生態圈，推廣代價等。。。看了很多答案，有些答案是把他歸於爹娘，有些是把他歸於有殺手鐧，感覺邏輯有點反了。
Worse is Better (http://dreamsongs.com/RiseOfWorseIsBetter.html) 能比較好地解釋題主的「為什麼」。注意這篇文章的寫作背景，這是一位 LISP 大佬在九十年代初反思為什麼 LISP 這麼牛的語言日漸式微，C 和 UNIX 這麼爛的東西卻起來了。概括下來大概是這樣的：
軟體設計有以下四大目標：簡單、正確、一致、完整，但兩大流派 MIT Style (MIT AI Lab 是 LISP 重鎮) 和 New Jersey Style (C 和 UNIX 的老家貝爾實驗室所在地) 對這些目標的優先順序排序不同。MIT Style 認為軟體正確性要絕對保證，然後優先順序 正確 ~= 一致 &> 完整 &> 簡單，簡單這一條還得分，為了介面簡單，可以忍受實現複雜。而 New Jersey Style 是正好反過來：首先軟體實現得簡單，做不到寧願讓介面複雜點，為了簡單顯然可以犧牲完整性，而正確、一致，那就儘力吧…… 反正得簡單。Worse is Better 前面的 Worse 指的就是像 UNIX 這樣為簡單甚至能放棄「正確」這種有絕對標準的好的東西，後面的 Better, 指的是更好的生存適應性，這裡面不帶價值判斷，文章作者也為 "Worse Is Better Is Worse" or "Worse is Better is Still Better" 一直在糾結，但這是一個能解釋很多現象的準確觀察。
沒錯，Erlang 就是 MIT Style, do the right thing 那個。它跟 LISP 一樣產生深遠的影響，會被無數後世語言技術借鑒 —— 即使不用 Erlang 開發我還是會對每個新人都會高度推薦 Erlang paper (http://erlang.org/download/armstrong_thesis_2003.pdf) —— 可是能火起來的，還會是那幫新澤西佬做出來的敢連 generics 都沒有的爛貨。
一個東西火起來的關鍵在於傳播。文章把 C 和 UNIX 比作病毒：它實現（而不是介面）很簡單，所以能很容易移植（感染）到別的平台，迅速跟原有平台的東西整合，因為它東西少，不拘泥於「正確」、「本質」之類的東西，能根據平台和需求快速演化，也能不斷吸(chao)收(xi) 別人的東西讓自己變得更強大。
但是 Erlang 不行，阻礙 Erlang 傳播的除了愛立信作死，還有它自己的特性。A History of Erlang 里數次提到，Erlang 很難移植到別的語言/運行平台，因為 Erlang 的運行模型太特別了（真可惜只有Erlang是對的），所以一切都只能自己搞，同樣原因要調用宿主平台的原有模塊也很困難。Erlang 有一個簡單、正確、不妥協的介面，但是底層實現就不得不非常複雜精巧，當底層實現的優化都不能滿足你的特定需求時，你很難繞過統一美好的模型做case by case, quick and dirty的優化。某個演算法 Erlang 跑太慢了你要引入 C 模塊，難（望向 PHP Python），複製消息傳遞通常不是瓶頸但如果變成瓶頸能傳指針么？NO, YOU"RE DOING IT WRONG! 當然實際上 Erlang 內部對這個是有優化的，大的 binary 會自動變一個引用計數 buffer 放共享堆然後就只用傳引用啦，但是這馬上導致一個問題，因為 Erlang 沒有（不需要有）全局 GC, 如果有進程已經不引用這個 binary, 但因為各種原因觸發 GC 遲了，共享 heap 里引用計數一直不清零這段 binary 就僵在那流量衝擊大你就等OOM吧，這是實際線上系統會碰到的問題，Binary是不是refc又不是你說了算，所以還是時不時自己強行 GC 一下…… 這其實就是一個介面簡單導致實現複雜優化困難並且難以做對結果還是要用戶自己動手的例子。Go 的 STW GC 雖然簡陋，但它不限模型，鼓勵複製但不禁止傳指針，對這種少數的 case 很容易解決，再拿個 pool 來對付一下蠢萌的 GC 就可以了。模型不純粹，實現極簡陋，但解決問題。
Worse is Better 也能解釋別的語言或技術的崛起。你不用很優秀但要有一個點做得好打到痛點，你不用設計完美但至少別犯大錯，然後保持簡單，保證好上手易移植易與現有系統整合，就可以了。包括 PHP（別打我），它架構上首先基於 CGI: 每個請求一個獨立進程，share nothing，只用管道跟 httpd 通信，這天然保證錯誤隔離，也讓 CGI 應用完全不需要管網路交互問題，短連接模型處理完請求就進程結束所以 PHP 甚至不需要 GC, memory pool 就行，更重要的是它也天然支持了熱替換。你可以說這些全部是 Erlang 的設計點，也完全符合 Erlang paper 提倡的把困難問題（HTTP server）做成框架讓業務寫得簡單輕鬆的思路，同時這也是傳統的 UNIX 編程方式 —— 這就是所謂設計上別犯大錯。然後再做一個亮點：直接 HTML 代碼里嵌入腳本，現在你覺得這很傻，但當時互聯網剛起來，HTML 還是新鮮事物，更沒有什麼 AJAX, 不用你自己組裝字元串直接把代碼嵌到 HTML 里太打動人心了。是，這沒什麼難的，但別人沒有，PHP 有。至於一台機撐多少連接？速度怎麼樣？當時有個人訪問你網頁你都興奮半天了，誰跟你研究這種吃撐了怎麼辦的問題？
如果 Worse is Better 作為一個定律是正確的，這聽起來很可悲，我們就活該沒有好東西用了。我感覺可以稍微修正一下：對於開發技術這種存在網路效應的東西，除非一個方案有革命性的優勢，否則都會服從 worse is better 定律。
在電信行業，Erlang 可能真的擁有革命性的優勢，我不熟悉的領域不評論，可惜電信行業本身相對狹窄封閉再加上愛立信作死，沒網路效應可言。而在其他地方，革命性的優勢，它沒有。
開發效率方面，@bhuztez 提到的好 8 倍，我記憶中來自 A History of Erlang 描述一個早期項目，對比對象是一個沒什麼公開信息的內部語言 PLEX，而且 Joe 說了原始文件從未公開，且當時內部爭議就很大；Erlang 標誌性項目 AXD 301 的報告結論 (http://www.erlang.se/publications/Ulf_Wiger.pdf) 是 4 倍，對比對象是 C/C++，方法是對比代碼長度（所有動態腳本語言都能贏好嗎）和bug密度（相同），更重要的是，它並沒有分析 Erlang 的語言特性在開發效率提高中的必然作用，甚至沒有代碼對比樣例（報告里倒是有一堆組織架構管理方法內容），也沒說明有 C++ 使用什麼能跟 OTP 對應的框架，這種論據拿到知乎上是會被噴死的。
運行時方面，Erlang 的高並發只能說它是生不逢時。90年代，除了電信領域，這種高並發需求實在沒有，要真有，QQ算？人家用 UDP 木有連接保持問題。當時的硬體情況，機械硬碟、網路帶寬、CPU 內存逐個撐死了都還沒輪到並發。Telnet-based BBS 是 TCP 長鏈接模型，用最基本的 UNIX fork 進程模型（操作系統級進程隔離，要不是這樣那十幾二十萬行sh*t還真跑不起來），中山大學逸仙時空用一台 98 年的 HP Alpha（以前的DEC）機器 2G 內存好像？能撐 3000 在線，水木PTT等大站有好硬碟好CPU 4G乃至8G內存20000在線不在話下，注意是在線，發獃會被踢的，所以這些連接的活動率很高（作為對比 AXD 301 用的是 Sparc Ultra 2 跑 Solaris 活躍進程有200-4000）。系統的瓶頸一是硬碟二是內存，遠遠沒輪到模型問題。到編程模型真有問題的時候，Worse is Better 已經發揮作用，各種現有開發平台借鑒 Erlang 模型可以搞出很好的東西 —— 為什麼是借鑒而不是直接用 Erlang? 答案 Joe 自己已經說了，他在 erlang paper 里鼓勵separate of concern, 框架模型這麼複雜的東西應該由專業人士一次過搞定，模型之上的應用就很輕鬆而且根本不用關注並發問題；在 A History of Erlang 中，他提到一個想法，Erlang 是一個運行平台，進程里跑的是什麼語言並沒有太大關係。那也就是說，雖然用別的語言山寨一個並發運行環境很難（而且很難做對），但是這只是一個一次性的工作而且可以根據業務特性定製，框架完成後，你還是可以用熟悉的語言寫業務，完全不用管並發問題，但同樣能達到好很多的並行度（所謂Actor / Reactor模型blah blah blah, 或者像MapReduce這種特定框架），而且只需要對少數關鍵模塊動手而不是全局替換，性價比高很多吧。
分散式支持的故事也一樣，Erlang 從原理上天然支持分散式，也很早就有了內置分散式支持。然而，這個支持所基於的假設也一樣老：幾個到十幾個節點，均質且可靠全互聯的網路，單一的全 Erlang 系統。Joe 怎麼也不會想到有人要用幾萬台破 PC 做集群還妄想跨洲跨機房熱備。到我們真的需要分布處理能力的時候，你會發現實現的設計假設限制了它的擴展性（http://release-project.softlab.ntua.gr/documents/ifl12.pdf），CAP 的基本限制在，不可能有一致、透明的分散式通信和狀態管理方案（[erlang-questions] State Management Problem 這個 thread 可以看到最後 Robert Virding 的總結陳詞），你還得去連不按 Erlang 規則來的別的服務，你也沒法把 mnesia 擴展到 GFS 的規模，因為它根本不是為這個設計的，Erlang 的這些先發優勢沒有變成劣勢已經很不錯了。現在回去看 GFS 和 MapReduce 的論文，你會覺得他們簡陋得可笑，裡面大篇幅的 fault tolerence 的東西，都是 Erlang 設計原則的特化和簡化，可是至少在那時，Erlang 沒有發揮它的威力，而 New Jersey guys 蠻幹硬上把東西做出來了。你甚至可以認為整個 Google 集群管理系統 Borg 就是一個大號 Erlang 平台，一堆 supervisor 在管著一堆 share nothing RPC 消息通信隨時會掛的服務（流行用語叫 micro service），絕大部分服務無狀態可以隨時掛，Goolge C++ 不允許拋異常但是規定你如果發現完全沒預料到的東西你應該直接打log crash掉等重啟處理，自動均衡部署容災一應俱全，幾乎無限擴展，處處閃耀著 Erlang 的思想光芒，但它們都是用 C++ 寫的。開源版 Kubernets 就是 Go 了，Go 沒有內置分散式支持，因為整個體系在，它自己已經不需要了。
這完全就是 Worse is Better 的原文：「The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.」
Google Trends, 全球數據，erlang vs. golang
答案最長的匿名用戶，根本就不懂go。
說1.5的GC渣，然而他居然說出「再配上引用計數器GC」，這是連基本的事實都未搞清楚。在他的回答里指出這點後，避而不談技術，最後拉黑刪評論。我就只好用回答來表達反對了。分明是自己認識不足，技術水平不夠，卻來怪語言這樣那樣，這樣的人見得實在不少。「控制不好就STW」，控制得好就能消除stw？1.5的gc，stw會控制在10ms內，你有多少網路服務的latency需求要比這個還高了？1.6及以後的方向是提高throughput，最大的改變是去掉佔cpu比較多的sweep操作。這些都了解嗎？隨口就說渣渣。以前覺得這類人怎麼說都好，跟我沒什麼關係，但最近覺得知乎上看到的技術內容越來越水，再讓這些槽點百出的回答污染timeline，哪裡能忍。
沒有什麼語言會因為一個人和一群人吵了一架就火起來。有成功的案例，別人看到了，試下水，認為適合，就會用。吵架就能吵起一個技術，舉個golang以外的例子看看？讓erlang也重現一下看看？360用著gc停頓可能有幾分鐘之長的go 1.0.3，做出了20台伺服器的2千萬連接的系統（官網博文里說的），發展到400台機器2億連接，這就是成功案例，可能推動其他人試用的案例，不是靠吵架。百度也有go寫的處理大流量的系統（知乎的回答里了解到的）。做web怎麼就不需要關注性能了？小看web服務嗎？還RoR，拿個快速開發框架跟一門語言比，什麼意思？===
另外不要把我看成是go粉，我認為粉或者黑都是不良的心態，只會阻礙人對技術的認識。許式偉和erlang一幫人吵時我也有參與，我是反對他的觀點的：如何看待許式偉談Go Erlang並發編程差異？ - 知乎用戶的回答 。erlang 如果是自由精英主義的話，go 就是新生代的實用主義……
erlang 不是不屌，是無論從招人還是項目維護上成本太高了，10個應聘的6個PHP3個JAVA1個其他，這個其他估計只有10%不到的幾率是個會 erlang 的，注意我說的是會，不是熟練or精通，面個試連 Actor 模型都說不清楚的那種，你是老闆你不心疼錢？加上沒有「一定無法替代」的理由，成為冷門語言就正常咯。
go 呢，首先他有個爹，然後他有個爹，最後他有個爹，沒了，就這樣粗暴。gc 怎麼了，stw 怎麼了，又不是人人做端游，又不是人人做高頻交易，連不是人人都用的模板都被干走了 go 爹真心不會在意這些小問題的。go 最大的優勢就是沒特點，沒所謂的「magic」，這對於工程來說簡直是完美。甚至 gmt 都讓工程師爭大括弧要不要新開一行的爭論都省了，沒模板編譯時中規中矩各種沒性格，直接拉低的是什麼，是人力成本啊。想想看一門語言，能 cover 90%以上的用況，還一次編譯到處可以跑，沒依賴，沒內存泄露，有並發模型，新人接手分分鐘，最重要的是它爹還特牛逼，怎麼可能不火。樓豬你問這樣的問題，是因為您知道的和了解的還不夠多，或者是因為各自的圈子不同而已。erlang的程序員也很多啊，誠然沒有像你說的golang,scala那樣子所謂的「很火」，但這也不能無視它的存在和實用性...語言的使用深遠程度沒有可比性。
變數不可變，函數式編程風格。這些雖然在並發場景下非常好，但需要開發者改變mindset，所以學習門檻很高（因為絕大部分開發者都是從過程式編程入門的）。所以社區小，所以沒有豐富的庫，所以社區小，所以沒有豐富的庫，所以沒有火起來。
因為用Erlang的人在加班，沒空上知乎。
----------------------------
我並不是黑Erlang，我是在黑遊戲行業。廣州做遊戲服務端的有不少公司用Erlang，上班時間996保底。然而前東家用Scala做遊戲也加班 （攤手）。儘管我們不需要加班就能完成進度，但老闆會覺得「竟然不加班，工作量肯定不飽和！」
這個語言要在中國流行起來先得把名字改改，呵呵
這是對Erlang極大的污衊！怎麼能這樣捏造事實呢！
Go和Scala根本沒崛起好嗎。Scala的爹是Haskell媽是Java，Go的爹是google，Erlang沒爹。
Scala確實牛逼，因為Haskell的背後是整個CS理論界，Scala凝聚了理論界幾十年研究的精華，靠幾個語法糖是戰勝不了的。所謂父精母血，爹給了精華，媽就給了平台和生態環境，java的平台也是無敵的。這就決定了他的出身之高。當然另一方面來說，這也就決定了Scala註定沒法獨屬於某公司，牽扯的利益太多，誰都擺不平，它只能從一開始就是開源的。所幸這個時代開源力量強大。有多少人是沒用過Golang，甚至連Golang更新內容都沒看過也沒研究過就胡亂給某匿名點贊的啊。。。
最大的鍋當然是愛立信的。明明是自己花了很長時間搞出來確實好的語言，卻因為不是公開標準或沒有開源實現拒絕在新產品中使用Erlang開發，這是什麼腦殘想法，難道就不能自己開源么？最後當然是開源了，可是這錯過了9個9的宣傳啊。本來是一個極好的讓業內非程序員都知道這門語言開發效率高的機會。
Erlang是一門精簡的語言，基本上只保留了真正有用的語言特性，目前除了模仿C語言的header和宏以外，就沒有別的語言里很多看上去無比花哨但實際上有和沒有沒區別的語言特性。就像XXX說的那樣，假如你已經學了某些流行的語言，你沒法通過學習掌握Erlang，你只能通過unlearn來掌握Erlang，這對很多人來說是前所未有的體驗。比如... the rest of the world was wrong and ... we were right
— A History of Erlang
https://twitter.com/cateches/status/670096508021161984
曾經使用過一段時間 Erlang，結論是：方便的地方真的方便，但麻煩的地方真的很麻煩。
最終放棄 Erlang 並不是因為社區，文檔，或者開源項目的多少，而是因為語言本身。首先是狀態問題，比如要在 Erlang中操作二維地圖，很多人都選擇用C來實現：
Erlang 如何操作遊戲中的二維地圖？ - 遊戲引擎Erlang寫無狀態的代碼是非常的爽的，代碼就像一個個數學公式把程序給 「定義」 出來，模式匹配有時也很高效。確實很適合電信系統這種請求與請求間隔離的，前後邏輯關係不大的「非狀態系統」，比如 HTTP，比如棋牌或者回合制遊戲。
但兩個請求間如果邏輯交互很頻繁，比如動作遊戲，ARPG，兩個角色間的交互頻繁了，牽扯裝太多了，用 Erlang就比較麻煩了，別人一個函數調用解決的問題，Erlang可能要幾個actor之間不停的消息中轉。
Erlang是一個專業化定製程度很高的語言（非狀態類電信系統，請求隔離），所以不能因為 Erlang 在有的地方比其他語言開發效率高8倍（儘管似乎號稱），就覺得 Erlang在任何時候開發效率都很高，比如你在 .BAT 文件裡面可以這樣：DEL d: emp*.jpg
換成 C++ 可能要寫7，8行，大家就覺得 .BAT比 C++方便一樣。處理文件和目錄或許是，但你說用BAT寫點除此之外別的東西，它就傻逼了，Erlang 也是一樣，方便的地方挺方便，彆扭的地方彆扭死你，關鍵還是 Scala 和 Go 的設計充滿了「妥協」，而 Erlang 里充滿了 「各種原則」。在適合的領域，這些原則能讓你很酸爽，而跳出那個圓圈，這些 「絕不妥協的原則」 會讓你花數倍的時間和精力去完成原本很直接的事情。
就像：帶著tt sex。
就像：穿著雨衣在跑步。就像：批著披風再游泳。用 golang的感覺是這樣：自由
因為大部分程序員水平不行。
替B大說的。（潑髒水（233寫過54萬字的erlang筆記，在programming erlang在國內出版前翻譯了1/3的篇幅並放到網上了。用erlang寫過一個memcache協議的伺服器端實現，以及一個http負載均衡。代碼經驗大約1萬行。參加過最初的兩屆ECUG。給python寫過erlang c node通信模塊。
也許是被Python寵壞了，感覺erlang真是太難用了。ERICSSON內部的鬥爭其實也很厲害。Erlang的產品並沒有表現出比其它語言產本更低的成本。 造成Ericsson決定不再使用Erlang開發新產品。
現在大家都在往雲上走，E///內部的決策是多產品共享雲的組件，如熱備等，但是這些東西在OTP里其實是自帶的，並且不能與其它語言進行共享，更進一步壓縮了OTP存在的空間。而且E///其實是一家比較總體謙和的公司，沒有美國公司那麼aggressive，所以在推動erlang的方面沒有花太多力氣。整個社區也比較低調。ErlangVM 的性能也一直沒有像JAVA那樣瘋狂的優化。E///的種種方面造成了現在erlang這種局面。不過就發展而言，現在大家逐漸開始意識到erlang的種種好處，而且越來越多的大公司開始使用erlang做為一些後台的支撐服務，像whatsapp, whisper, facebook, 盛大，騰訊等等，算是厚積薄發。 反觀go，可能我孤陋寡聞，除了某家天天跳下跳下的公司外，並不知道有哪些大公司在積極的使用它，我個人對erlang的發展還是相當有信心的。最近接觸了一段時間 Elixir ，同時也試了試 Erlang，感覺 Erlang 的語法太那個，因為變數的固定性，有時候一連串的序號，看得人眼花繚亂。但現在國外有些創業公司，或者新項目，都已經從Ruby 轉移到 Elixir 上了，他們並沒有選擇 Go 語言，理由是，Erlang 強大的容錯性，易擴展性，加上 Elixir 元編程帶來的極大靈活度，讓他們最終選擇了 Elixir。
我覺得 Erlang 不流行的原因是，相關的輔助工具太少了，連個像樣的開發文檔都沒有，官方的開發文檔太簡陋了，還有就是 Erlang 的語法讓熟悉 C 語法的人的特別鬱悶和變扭，還有是，Erlang 不太適合很小的項目，它好像更針對那種超大型的分散式系統。這種系統並不是哪種語言能解決的事，它需要很好的設計，這並不是一般人，1,2個人拿的下的。最後是， erlang 的數學的計算能力，比起其他語言，效率太慢了。
它並沒有非它不可理由，肯定被Java和PHP擠出了市場。Java 的容錯能力和並發能力本身都不差。
不過，在國外 Erlang 的流行並不遜色於 Go 和 Scala，原來 Facebook 的聊天軟體就是 Erlang 寫的，Go 也沒有想像的那麼流行，稍微有一點實力的公司，大部分核心的工作，還是 C 和 C++ 在兜底。首先這幾個語言我都沒寫過哪怕一行。
我覺得因為Go暴露了Actor和Channel自己同步原語(就允許用戶自己定義使用當時和思維)，且他具備類C的結構化編程和鴨子類型以及GC。這 這讓業務不複雜(不太需要強大的C++，傳統C就足夠)！，且不要出現段錯誤(gc支持)的系統很格合適，而且稍加設計就能利用多核。
而Erlang則是純粹的Actor模式的函數語言，語言本身確實很簡單。但更多人卻(不熟悉他的模式，類型系統，思想，範式)無法hold住他來開發業務。而Go拋開Channel和協程，至少你能當成一個不需要手動管理內存的C語言！！！
所以我個人是不會用Go的，因為我自認為能hold住C++，我也喜歡C++的強大，雖然我的工作內容用Go也能實現。另外，如果哪天我需要Actor(意指業務系統真的就很切合這個模型，彼此之間就只消息通訊)，那我肯定選純粹的Erlang；也因為（這種時候）Go的其他設施對我而言沒多大用。
另外一門語言我沒了解過，因為那是建立在JVM上的，我對Java有偏見。HASKELL嘛，因為vczh說它牛逼，我就看了下，沒學會，也永遠不會學了。
(不吹不黑)以上有說錯的地方，還請指證。非要拼爹，Erlang的爹(Ericsson)在作威作福的時候你們的Google/Oracle/TypeSafe還不知道在哪兒混呢。
而且，Erlang也是有貴(xue)族(shu)血統的好伐。不信出門右轉去看看Prolog。
說白了就是不惜得和你們整那點根本無關痛癢的名利。
換句話說，火了又關你屁事？就是這樣。有沒有erlang的小夥伴要換工作？我這邊有工作推薦，工作地址的廣州天河，要求一年開發經驗左右，項目成熟，有獎金分紅。有意者加扣扣吧 644857038
其他不知道，但作為曾經的go腦殘粉，我現在覺得一門沒有generic的強類型語言很多時候讓我有種被強制壓低智商的感覺。
推薦閱讀：
※如何看待「Go 2.0」？
※如何看待GO語言的新GC(TOC)?
※這樣一段代碼在軟體工程界屬於什麼水平？
※現在想再學習一門編程語言，應該選擇go還是python？
※Golang 的並發與 Erlang、Scala、Node.js 和 Python 的並發模型相比有何特點？
TAG:Scala | Erlang編程語言 | Go語言 |