扯淡 erlang 的“適合”和“不適合”

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

現在在體系內大力推廣erlang了。不過挺遺憾的是，推行 erlang 前並沒有對這個語言自身進行深入的論證和研究，只是由核心人員寫了一個簡單得不能再簡單的 demo，在項目裡用了一個開源的 erlang 項目。從工程的角度來說，這是不靠譜的，為了讓 erlang 的使用更加靠譜，所以在這裡扯淡一下。資料來源於erlang官方和我的猜測，對不對由我，信不信由你。

先看來自 erlang FAQ的內容（自己隨手翻譯的，不一定準確，可看原文：http://www.erlang.org/faq/introduction.html#1.3）：

——————————————————

1.3 Erlang 特別適合使用的項目是什嗎？

分布式的，可靠的，軟即時並發系統。

* 電信系統，例如控制交換或者協議轉換

* Internet應用伺服器，例如郵件傳輸代理程式，IMAP-4 伺服器，HTTP 伺服器，WAP棧

* 電信系統，例如處理移動網路的切換或者發布統一格式的訊息。

* 需要軟即時功能的資料庫應用

Erlang 在最初設計時有明確的處理問題的範圍，所以 Erlang 在處理一些問題時會有很好的表現。下面有一些該類問題的特徵描述：

* Erlang 提供了簡單並且有效異常控制和容錯機制（受監管的進程）。

* 並發和訊息傳遞是語言的內建機制。使用 Erlang 編寫的應用通常保持數百甚至數千輕量進程。Erlang 進程的環境切換的開銷，比 C 程式的線程一般要少一到兩個數量級。

* 開發運行在不同的裝置上的應用（例如分布式應用）變得容易。Erlang 的分布式演算法是透明的：程式不需要知道他們是分布的。

* OTP 庫提供了許多網路和電信系統的一般功能的支援。

* Erlang 運行時環境（一個虛擬機器，類似 Java 的虛擬機器）意味著代碼“一次編譯，到處運行”。同時，運行時系統也允許在不中斷程式執行的前提下對正在啟動並執行系統進行更新。

===========================
1.4 Erlang 不是特別適合使用的項目是什嗎？

令人驚訝的是使用者在所有可能的地方使用 Erlang，一個例子是在協議層級同 X11 通訊，但是，一些情況下 Erlang 並不是應該被選擇的語言。

最常見的“不太適合”的問題是效能需求是最主要的，並且客觀因素對效能有極大影響。有代表性的例子是影像處理，訊號處理，排序大量資料和底層協議中斷。

另一個類別的問題是大量涉及 C 代碼。有代表性的例子是實現作業系統裝置驅動。

多數（全部？）使用 Erlang 開發的巨型系統，可能在底層代碼上大量使用 C，離開 Erlang 去管理在其他語言中傾向於複雜的部分，如控制系統在數個機器上的分布和實現複雜的協議邏輯。（這個翻譯有疑問，到底是在這種情況下不要用 Erlang，來由自己實現呢？還是交由 Erlang 來管理呢？）

——————————————————

如果我沒理解錯，FAQ透漏出一個資訊：Erlang 的目標主要是用在大規模通訊這類應用上。對於高並發的資料流I/O應該是不錯的選擇（例如網關、資料交換等）。而對於複雜的商務邏輯處理或高效能的數值計算並不在行（如遊戲中的遊戲邏輯）。

不過我這裡有一份很舊的文檔（看時間應該是 2006 或 2007 年的）顯示，使用多語言混合的 Erlang 應用，效率可能還不如純的 Erlang 應用。主要原因是 Erlang 的輕量進程的切換開銷，要遠小於同其他程式通訊時造成的進程切換開銷。

好吧，扯淡了這麼多，上點猛料。內部推廣 erlang 的時候，並沒有這些資料，不過我覺得很有意義：

一個基於 erlang 的 MMO 引擎：http://sunweaver.blogspot.com/

編寫基於 erlang 的 MMO 伺服器：http://www.devmaster.net/articles/mmo-scalable-server/

一個基於 erlang 的 MMO 架構：http://www.next-gen.cc/

由上面的 MMO 架構引出的討論：http://news.ycombinator.com/item?id=981597

另一個關於 erlang 在 MMO 應用的討論：http://www.blitzbasic.com/Community/posts.php?topic=75515

哦，對了，另外推薦個材料，關於 go 的：http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

go應該說從某些方面彌補了 erlang 的短板……

2月28日補充：

Tim 已經很好的做了一個關於C（nginx）、Erlang、Java 和 Go 的測試：http://timyang.net/programming/c-erlang-java-performance/ 測試很完整，不過後面的 comments 更精彩！如果體系內有人能夠在推廣新東西的時候，做一些類似這樣令人信服的工作就好了。

另外，在 Tim 的 comments 中有人給出了這個東西 http://www.javaeye.com/topic/107476 雖然是好多年前的了，但也很有價值。

不過個人切以為，當然好的語言能夠如虎添翼，但是就現有項目期望的並發和負載量，語言選擇絕對不是技術上的瓶頸本質……呵呵……

3月2日補充：

舊文一篇：http://www.javaeye.com/news/3510-joel-reymont-of-complaints-erlang

這個文章本身沒什麼，裡面的一些觀點和思想可能在這麼多年後也有更新，不過評論裡有個朋友說得非常好：“沒有將一個遊戲系統很好的分成不同的子系統，他那樣的作法，無論使用哪種語言，到最後系統擴充起來，都會有很多的麻煩”，“在系統規划上沒有足夠的經驗，或者說沒有足夠調查分析”，“使用ＯＯ的思想做ＥＲＬＡＮＧ，就是一個方向性的錯誤，erlang是不支援ＯＯ的”。

這位朋友的評論，正好說出了我們已經犯了的，或者正在犯的，甚至將要犯的錯誤！！！

3月3日補充：

今天在地鐵上看著湧上、湧下的人群，我突然頓悟：對於即不關心架構，又要求效能。即不懂 worker、perfork，又要求多核的他們來說。的確！Erlang是最好的選擇。甚至是唯一的選擇！

3月7日補充：

強大的python，一個用 python 實現的 erlang 節點：http://www.lysator.liu.se/~tab/erlang/py_interface/。哦，對了，在對 erlang 整體研究過後，發現體系內需要的其實不是 erlang 這個語言，而是 erlang 這個架構。也就是需要一個面對程式員透明的分散式運算的架構，呼……