Erlang 二十年，如何在編程語言中佔據一席之地？

1998 年開源發布的 Erlang 項目，在全球範圍內只是個小眾編程語言。

根據 TIOBE 最新發布的語言排行榜，Erlang 僅排名在第 65 位，市場份額佔有小於 0.1%。但是作為一門函數編程語言，它擁有著強大的並行處理能力和容錯機制，簡單好用且易學。最開始，Erlang 之父 Joe Armstrong 編寫的初衷針對的是類似於電話交換機那樣的高可用性、高可靠性系統，但後來卻成就了可靠性達到 99.9999999% 的目前世界上最複雜的 ATM 交換機！

須臾二十載，如今的 Erlang 項目仍然煥發著生機，並在技術淘汰中穩穩站住了腳跟。那麼 Erlang 在這些年中經歷了哪些發展階段？Erlang 語言的知識階梯如何影響了對它的採用？Erlang 及其社區未來的發展方向是怎樣的？......下面就讓我們一探究竟。

聲明：本文已獲作者 Fred T-H 翻譯授權。

作者 | Fred T-H

譯者 | 蘇本如，責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

大約在10年前，我加入了Erlang社區，當時正值Erlang語言的第一個炒作階段。我們都被告知，Erlang語言代表著並發性和並行性開發的未來，因為它能夠以最輕鬆和最快速的方式完成開發。你還可以得到免費的Erlang分發包，因為它已經變成了一個開源軟體。在那個年代，一切都開始變得不可思議。虛擬機也剛剛獲得了SMP支持，而在此之前，要想真正利用同一台計算機上的所有CPU，你必須在那台機器運行多個虛擬機。

在這篇文章中，我想先花點時間對這十年的大部分時間作個反思。然後我會介紹一些這期間發生在Erlang上的事情，例如炒作階段對Erlang的影響？Erlang語言的知識階梯如何影響了對它的採用？以及我在Erlang社區的十年中自身發生了什麼變化？最後，我將探討一下我認為Erlang及其社區的發展方向。

炒作階段

炒作周期（或技術成熟度曲線）在一個產品或技術的生命周期中引入了「階段」這個概念。這是一個營銷概念，而不是一個科學概念，但是用它來描述事情的發展往往會很有用。而我最感興趣的部分是「炒作階段」，它就像一股發生在編程社區的淘金熱。你可能見過一個或多個這樣的炒作階段，通常他們似乎都依附於某個殺手級應用程序，吸引著每個人蜂擁而至。

我能想到的「炒作」的例子有：炒作Ruby on Rails的「如何在15分鐘內構建一個博客引擎」的視頻（https://www.youtube.com/embed/Gzj723LkRJY，其中的「看看我沒有做的所有事情！」仍然是一句有趣的話），炒作Kubernetes 的「在Kubernetes下使用Go語言」的文章（Kubernetes在此以前已經有了大量使用，但在那之後確實進入了一個爆發期）。在某種程度上，對Elixir和Phoenix的炒作或許也可以列入這個名單。

在這樣的一個炒作階段，大量的新來者蜂擁而至，都想來看看能撈點什麼好處。有些人會留下，但多數人會很快離開。大多數人的停留時間可能只是幾個月或幾年，能真正地安頓下來並且堅持幾十年的人非常少見。絕大多數人都是一些絡繹不絕的先期採用者，他們從一個技術衝浪到另一個技術，嗅探最佳的機會，希望先行採用某種框架、語言或工具包，來獲取一定的競爭優勢。

所以通常的想法是，首先你要擁有一個真正的殺手級應用程序，然後人們就會湧入你的生態系統。殺手級應用程序會驅動這股人潮，只要你把它構造出來，人們就會蜂擁而至。如果你能留住他們中的小部分並保持他們的活躍度，那麼在可以預見的未來，你將會擁有一個活躍的社區。這用一種奇怪的方式，讓我想起了「雨隨犁至」這個理論：

上帝加快犁地的速度。……這是奇妙的「人類主宰自然」的理論假定，天上的雲會分配取之不盡的雨水…而[犁]是讓野蠻變成文明的工具；能把沙漠變成農場或花園。……或者更簡潔的表達，就是「雨隨犁至」。

這一理論的基本前提是，通過人類的定居和農業活動可以影響乾旱和半乾旱地區氣候的永久變化，使這些地區更加濕潤。這一理論在19世紀70年代被廣泛推廣，作為美國大平原（曾被稱為「美國大沙漠」）開墾定居的理由。這也被用來證明南澳大利亞在同一時期的邊界土地上小麥種植的擴張是合理的。

如果我們能讓一個大項目一直進行，開發人員就會出現，然後它就會自我維繫下去。我認為這種觀點顯然是錯誤的，因為儘管Erlang在其最熱的炒作階段擁有了數十個殺手級應用程序，但是，它的社區仍然維持在很小的規模。下面，就讓我們看看在那個時代，Erlang都有哪些殺手級應用程序：

• ejabberd（誕生於2002年，第一個穩定版本發佈於2005年）：它是迄今為止最具可擴展性的主機聊天伺服器之一（即使不是之最）。Ejabberd曾經是一個巨大的成功，在某種程度上來說現在仍然是。到目前為止，在StackOverflow上仍然能看到關於它的模塊的提問。在2011年左右，它衍生出了MongooseIM分支，現在這兩個解決方案仍然處在維護中。

• CouchDB（2005）：是根據CAP定理，用Erlang編寫的第一個流行資料庫，也是當時新潮的多主文檔存儲解決方案之一。雖然現在MongoDB是該領域的王者，但CouchDB在存儲引擎方面仍然有其精神繼承者，最出名的是BarrelDB，它現在還在維護中。

• RabbitMQ（2007）：幾乎佔據整個AMQP市場的一個消息隊列軟體，它現在仍在用並且很有價值。在流式工作負載方面，它經常被和Kafka一起討論，儘管它們具有明顯不同的特性和用例。

• Facebook Chat（2008）：Facebook Chat的初始版本是用Erlang編寫的。由於許多內部因素，如系統穩定性的考慮，和內部C++工程師的強勢地位，以及已經有了C++實現的一套解決方案等等，後來它用C++全部改寫。

• WhatsApp（2009年，2014年被收購）：在Facebook的聊天系統擺脫了Erlang語言後，他們最終購買了WhatsApp這個眾所周知的只用了50個工程師開發的服務於9億用戶的跨平台應用程序。它今天仍在使用，事實上，WhatsApp的開發者決定比以前更加深入地參與Erlang和Elixir社區中。

• Riak（2009）：是分散式系統世界展現自己優勢的最佳例子之一。Riak是一個真正可靠的分散式鍵值資料庫店，它是Basho Technology公司開發的一個當前仍在醫療保健系統和其他關鍵基礎設施中運行的NoSQL資料庫產品。在Basho Technology遭遇財務危機並被迫破產時（這在很大程度上是因為公司違反了信託責任，迅速走向了敗亡），Bet365買下了它的所有知識產權，並優雅地將其開放源代碼，現在Riak資料庫仍然在開源世界中運行，儘管它的支持力度和過去最好的時期比稍稍不如。

以上提到的殺手級應該程序，很多都是在喬·阿姆斯特朗的《Erlang編程》一書問世的時候出現的。它們製造了一場對Erlang大量採用的完美風暴，同時也為Erlang吸引了大量的旁觀者，甚至對黑客新聞網站都產生了明顯的影響，以至於它強制要求在某一天所有討論都必須是關於Erlang的內部機制。

然而，喧囂之後，留下來的人很少。

我認為，現在的殺手級應用程序的出現和過去相反，它是出於人們想在最初的炒作階段分一杯羹的貪婪。任何應用程序，總有一個弱小的、早期的階段，有人嗅出了它技術的有趣之處，決定喜歡它，並且將它構建出來，如果碰巧它成了一個殺手級的應用程序，那麼就會進入一個更大的炒作階段。人人都盼望從天上掉餡餅，一個成功的故事會培養更多的模仿者。另一個常見的現象是「重塑世界」階段，每個人都花時間重新實現現有的一切，所以你會看到很多很多「與語言無關」的公告。

但是殺手級的應用程序本身從來就不能夠實現開源語言的自我維繫。其中一個有趣的結果是，像RabbitMQ和Ejabberd這樣的產品，儘管很受歡迎，但其用戶社區比貢獻者社區要大得多。成千上萬的公司使用他們的產品，但他們不一定會參與到Erlang社區中來。

毫無疑問，部分原因在於Erlang的大多數殺手級應用程序都在專門的基礎設施中：你創建了一個其他人都可以使用的高可靠性黑盒組件，如果它工作得足夠好，他們就不需要查看盒子內部。現在好了，幾十個開發人員已經為數千種其他產品和服務提供了基礎設施。而按照定義，專業化的基礎設施是一個不需要大量人員就能產生巨大影響的地方。所以它們的貢獻者群體和社區總是比靠近最終產品的群體和社區要小得多。例如，擁有數不清的網頁開發人員的Web開發框架，或者更通用的基礎設施，都可以把它們用到小規模的部署項目上，因為任何企業都可能找到它們的用途。

但是，即使沒有這些因素，也很容易讓人覺得，Erlang錯過了一個巨大的機會，那就是它在炒作階段沒有獲得更大的蛋糕份額。

知識階梯

我不想用諸如「過去可以發生或者應該發生」這樣的描述來做反事實推理。相反，我想挖掘我在Erlang社區多年的教學和寫作中所看到的常見學習模式。這些也是我現在正在Elixir社區中看到的模式，我覺得這可能是預示著Elixir可能有著相似未來的一種跡象。

我最鍾愛的一個理論是，像編程語言（及其生態系統）這樣的技術主題具有多層複雜性，需要學習和發現各種概念。我第一次開始表達這種理論是在Learn You Some Erlang的網站上，用一個我稱之為Erlang第九圈的圖表。

我認為學習一項技術並不是無休止的痛苦（至少，它不應該如此），這話是不是說得有點假心假意，我只是喜歡雙關語。但簡單地說，對任何新技術的學習，通常有一個更「核心」的主題路徑或次序，這樣就有了「知識階梯」這樣的東西，在這個知識階梯上，越有價值的知識/概念被放得越高，也越難到達，所以實際情況是，到達越高的地方的人會越來越少。

對Erlang來說, 我認為它的「知識階梯」可能是這樣的：

1. 函數式編程；

2. 隔離進程和並發性；

3. 可靠的並發性（links, monitors, timeouts）；

4. OTP行為模式和其他系統抽象；

5. 如何構建OTP系統；

6. 如何構建發布版本並處理其生命周期；

7. 如何保持系統始終在線，以及如何運作。

如果你是第一次接觸Erlang，並且從一本初學者的書開始學習，你可能會在第一級階梯上花費大量的時間：與函數式編程、不可變性、遞歸和類似的概念交朋友。遲早，你會接觸到並發性和並行性、進程和消息傳遞。在那之後，你開始學習links和monitors進程監控，錯誤處理，以及Erlang的內部機制。在Erlang的大炒作階段，第二級和第三級階梯成了最讓旁觀者驚嘆的賣點。如果你必須學會一些在未來的項目中必備之知識，那就是其中之一。

其他的梯級會在稍後跟進，尤其是OTP（第4級階梯），但前提是你堅持完成編程這一階梯。OTP被視為Erlang的真正價值所在——並發性和函數式編程確實不錯，但是OTP代表的一般開發框架是你必須堅持和使用的真正獨特的東西。很多人願意使用這些框架，了解它們所做的美好的抽象，但是對於如何正確地構建每件事情可能會感到有點困惑。

事實上，像Ejabberd這樣的應用程序的大部分開發幾乎沒有突破第四級階梯。當時的生態系統有點像蠻荒的西部，對於愛立信的員工和最有動力的自學者來說， OTP知識也就是那麼一回事。大多數人只有在有值得投入生產的東西出現問題、並且想尋找更好的解決方法時，才有可能到達第五級。直到2015年或2016年，當Relx的出現開始讓整個發行體驗變得更容易時，第6級才被重視。第7級幾乎從未到達，事實上，很多人都覺得不應該熱升級一個節點，理想情況下，你也不會在生產環境中使用SSH命令行進行調試操作。

在實踐中，並非每個人都會按照相同的順序來學習所有這些知識，有些書會調換它們的次序（這讓我想到了Erlang and OTP in Action這本書）。我覺得這些次序都不是問題，「階梯」用在這裡只是為了說明問題。

社區波浪式向前發展。炒作階段會使一個社區的規模增加十倍甚至百倍，大多數人會好奇地看一眼然後離開，所以一個社區中的大多數用戶傾向於停留在第一個梯級。少部分人會到達高一級階梯，更少部分的人會到達更高一級，依此類推，直到你擁有到達最高階梯的內部專家圈為止。

對於Erlang來說，我認為前三個梯級可能是最容易到達的。第四個階梯花了幾年的時間來開發，最終被認為是有價值的。第五個階梯非常複雜。Erlang缺乏工具和生態系統，Erlang社區留下來的都是自己選擇的，願意忍受這種貧瘠環境的人，因此對新來者的困境不敏感。為了保持這篇文章簡短（好吧，長而不是荒謬的長），我就不在此贅述了。

在任何情況下，如果你是一個Elixir的用戶，你可能會看到你在這個硬性定義的階梯上的位置，你可以感覺到一個社區中的派系通常都在那裡。很多人，可能他們只是在Phoenix上做得很好，很少能突破第四階梯，而且在可預見的將來，他們中的許多會一直停留在第三階梯或以下。在許多情況下，這些情形都是對的。這裡我們只是觀察，不作評判。作為一個通過了很多知識階梯的人（可能在這種環境中，我的頭上還有一些知識階梯，比如「修補虛擬機」之類的），他們似乎錯過了很多知識階梯，但坦率地說，那些東西對他們可能永遠不會有用。

但所有這些都是說：作為一個社區，我們可能會讓人們很難超越基本水平，從而使我們自己陷入困境。經驗教訓的學習是不可以一蹴而就的，在某種程度上，Erlang社區是盲人在引導盲人，因為它實在太小了，沒有足夠的人來分享所有需要的經驗。今天的情況比較容易，如果你在一個炒作的周期之外，你很可能會找到好的幫助，因為很少有人同時要求所有的幫助。

我想表達的是，如果明天Erlang有第二個炒作階段，我們會比上一個炒作階段表現得更好。希望這些經驗，加上Erlang和Elixir社區之間更好的合作，讓我們能夠接觸到更多的受眾，讓我們成功的機會加倍。

Erlang有哪些改變？

Erlang不是一具放在一個裝滿甲醛的玻璃容器里的屍體，等待在光天化日之下被帶走——它一直在進化。部分原因是由於Elixir社區的壓力和需求，幸運的是，他們對自己的工具的期望比Erlang用戶已經習慣的要高。另外部分原因在於推動平台向前發展的實際工業需求，而不像學術界，他們只是按照他們自己喜歡的方式推動事情向前發展。

以下是我能想到的一些改變，大家可能很高興知道有些變化在2009年或更早的時候就發生了：

• 多核支持現在工作得很好。最初支持2-4個內核的時候，開發人員經常碰到各種超出自己控制的瓶頸問題，後來就可以很好地處理12-16個內核了。而現在我不太確定能支持的內核上限是多少，但有一點我很確定，我寫的堆棧操作運行在超過32個內核的機器上沒有任何問題。

• Stacktrace異常跟蹤報告支持行號。回到沒有行號的年代幾乎是無法想像的，在那個年代，「寫簡短的自我描述的函數」不僅僅是一個設計問題，也是一個生存問題。現在，你不再需要超自然的調試技能，就可以調試Erlang程序。

• Unicode支持現在可以接受。string模塊包含最重要的演算法，Unicode模塊可以很好地處理大多數轉換和規範化，處理raw codepoint、utf-8、utf-16和utf-32的一般策略已經具備。本地化支持仍然缺乏，但現在一切都可行，諸如re（用於正則表達式）和所有更高級別的文件處理代碼之類的模塊也可以很好地處理unicode。

• 支持映射（作為HAMTs實現），具有明確的模式匹配語法。使用Dialyzer對其進行的類型分析也可以將其替換為多個使用案例，在這些案例中，以前使用的記錄非常痛苦。

• 虛擬機中的時間處理機制是世界級的，在處理時間規整、各種類型的時鐘等問題時，都可以很好工作。不過，時區和格式處理使用社區庫仍然更好一些。

• 添加了atomics、counters和persistent terms等高性能工具，以幫助改進所有增強可觀測性功能和較低級別核心庫的底層機制。

• 所有信號處理都是非同步的，包括埠，大大減少了瓶頸。

• 編譯器正在重寫中，以便通過SSA獲得更高級別的分析和性能提高。

• 運行NIF的臟調度器已經可用，使得與C甚至Rust代碼的集成變得簡單，同時支持IO密集型或CPU密集型工作負載。因此，儘管該語言可能不會無限快，但它已經快過其它語言。在對運行時穩定性不造成太大影響的情況下，為獲得更高性能的庫而停機比以往任何時候都容易。

• 內存分配和管理的各種改進。

• 更快速、更靈活的實時跟蹤和微觀狀態分析，以保證正確運行和性能調查。

• 更靈活的gen-statem OTP行為模式，以實現能夠處理選擇性接收的有限狀態機。

• 新的改進的日誌框架，內置對結構化日誌的支持。

• 重寫crypto加密模塊以便使用NIF，而不是更複雜（通常更新速度較慢）的驅動程序。

• 使用NIF對文件驅動程序進行整體重寫，以獲得巨大的性能提升。

• 使用NIF對網路驅動程序進行重寫的工作正在進行，以獲得類似的性能提升。

• 對用於TLS處理的SSL應用程序進行整體重寫。這讓我想起我在HeloCu工作的日子，通過整體重寫使其與C++解決方案在延遲（可能慢5%）方面具有競爭力，並且在可預測性方面總體上要好得多（大約10-30倍的提升）。

• ETS性能的主要改進。

• 我編寫了一本關於如何使用Erlang VM操作和調試生產系統的手冊（https://erlang-in-anger.com/）。

• 全新的構建工具（rebar3），與Erlang生態系統的統一軟體包管理器集成。

• 在虛擬機上還提供多種新的編程語言，具有可替換的庫用法。包括（但不限於）Elixir、Efen、LFE、Luerl、Clojerl，以及至少兩種使用Gleam和Alpaca進行類型推斷的語言。

• 其它更多針對核心Erlang分發包的內部和外部的改進。

如果你有興趣了解更多信息，你可以查看版本發布說明的完整列表（https://www.erlang.org/news/tag/release）。但簡而言之，如果OTP 版本13到16的發布時間對愛立信（Ericsson）OTP團隊來說有點晚的話（我們現在已經是版本22！），那麼他們使用Erlang對他們的旗艦產品中所做的最新投資確實是顯而易見的。但即使在愛立信之外，一切都在發生變化。Erlang社區，以及Elixir社區和運行在Erlang VM上的其他語言的貢獻者，都聚集在一起建立了Erlang生態系統基金會，現在它擁有一個活躍的工作組，幫助協調和解決有關構建和打包工具、可觀察性工作、安全性、培訓和採用等問題。

如果你像我一樣，在大炒作初期加入Erlang，但又沒有像我一樣留下來，因為你覺得很多東西不可用或太棘手，你可能想再試一次，因為Erlang的語言的人類工程學及其生態系統已經大大改善。

Erlang將去向何方？

雖然沒有必要像2007年到2009年那樣突然出現大殺手級的應用程序，但這並不意味著沒有任何項目顯示出這種希望。Erlang仍然是許多公司的基礎設施的不可缺失的部分，其最初的殺手級應用程序大多還在其上運行。我們也有很多有趣的新應用，就像每個BEAM配置文件顯示的那樣。我自己真的很喜歡基於屬性的測試等概念，並且Erlang和Elixir擁有世界上最好的框架。儘管如此，跡象表明我們現在還沒有進入炒作階段。

會有另一個炒作階段嗎？也許有，也許沒有。你可以說，Elixir會有下一個炒作階段。生態系統都有足夠的共同點，在一個地方學到的經驗教訓可以用到另一個地方。它們之間的相似之處多過不同之處。也許還有一個新的復興時期，我個人不再那麼在乎它了。我喜歡小社區，所以我對此感覺很好。Erlang不需要幾何級增長來讓我覺得樂在其中，它只需要可持續發展。

Erlang社區的規模大小也從來沒有阻礙它在全世界發揮它的影響力。就我所知，Erlang一直處於這樣一種狀態，既沒有足夠的工作量滿足Erlang開發人員的需求，同時沒有足夠的開發人員來完成Erlang的工作：這兩個方面都有很多工作要做，但他們在地理位置上並不一致。面向偏遠市場的公司和員工往往做得最好。而在Erlang之前無法輕易突破Webapp市場的地方，整個Elixir的就業市場現在只需稍加努力就能達到良性循環。

從一個更高的層面來看，你是否使用Erlang或類似的語言，這可能並不太重要。雖然我確實覺得它沒有被充分利用而且它的價值被低估了，但最大的好處不是來自於運行一個使用它的系統。而是來自於學習可靠系統設計的基本原理，並在實際環境中吸收其經驗教訓。

我多年來聽到的一類問題都和尋求指導有關。例如，我應該如何學習系統設計？關於構建分散式系統，你有什麼好的建議嗎？我應該做什麼可以讓系統變得更加健壯和容錯？我怎麼知道我的設計是模塊化的，不會導致抽象泄漏？什麼是良好的錯誤處理？有什麼好方法可以讓我知道優化工作還為時過早呢？聲明（declarative）某個東西意味著什麼？

我們總是喜歡簡短易懂的解決方案，如食譜和最佳實踐，但事實證明，大多數真正的答案都是「我花了很多時間學到的」或類似的東西。我可以坦誠地說，我的職業生涯中沒有什麼能比得上花時間在Erlang世界裡，潛移默化地吸收社區里老手們的豐富經驗。從數量上看，Erlang不是一個大的社區，但從任何其它指標來看，它肯定是富有的。幾年後，我從一個初級開發人員變成了高級開發人員，在世界各地發表演講，尋找方法把我獲得的這些經驗傳授傳大家，這其中大部分都歸功於Erlang這個社區。

也許我在15分鐘內還是寫不出一個博客引擎（事實上，我不是一個快速開發人員），但我已經成為一個更加可靠的開發人員和系統架構師，我認為這是一種非常有效的方式。再說一次，我在這裡討論的不是使用系統，而是構建它們並使它們工作。無論如何，激勵人們的東西並不隨處可見。

我無法想像我能在其他社區能得到這麼多，過去的10年里發生的一切令人驚嘆。有趣的是，Erlang社區仍然很小，大部分還沒有開發利用。這意味著你有足夠的機會參與到任何事情中去，與那些充滿智慧的人一對一地進行交流，並為自己爭取一席之地。

原文：https://ferd.ca/ten-years-of-erlang.html

【END】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！