Erlang到底好在哪里？

因為能力有限，對Erlang的了解僅限皮毛，本文只做簡單了解.

從技術上說，Erlang是一個平臺，她提供了一套完整的高性能、高可靠網絡服務開發所需要的基礎設施，并提供了原語給開發人員使用，她降低了開發類似系統的難度與門檻.有一個說法，Erlang讓一個中高級程序員，用一半的時間，一半的代碼量，就能提供頂尖C程序員開發的網絡服務80%性能的類似系統，并且可靠性不輸于甚至超過前者。實踐證明這是真的.

另一方面，Erlang也給了開發人員強大的自信，就如同前面開發DSF時的場景所述.有開發維護過線上系統的人應該可以深刻的感受到，開發一個高可靠的網絡服務有多困難，維護一個線上系統有多勞心，當一個服務上線時，我們的運維與程序員即使睡覺都恨不得睜著一只眼睛.

采用Erlang開發的系統，其出現的bug量與用常規語言開發的絕對不是一個數量級；Erlang的監控樹機制，更是讓我們的服務，天生就具備了高可靠的基因，只要稍花精力，仔細規劃我們的監控樹與重啟策略，就可以讓本來就少了很多的bug及一些無法預料的外部故障，在即使出現時也有很大的幾率迅速恢復，給你修復bug排除故障一個緩沖的時間，更何況，Erlang可是具備熱更新能力的，那真的可以讓你延壽啊！延壽！

如果你的老板問你，為什么要用Erlang，Erlang好在哪里，你可以這樣總結：省錢.你想想，一個資深的、頂尖的程序員與中高級普通程序員之間的成本差，普通的系統就只要普通的程序員就好啦，那不僅僅是省錢，是省很多很多的錢.

Erlang的優勢與缺陷

Erlang在消息執行方式上的優勢在于靈活.Erlang是弱類型語言，在實現的時候可以任意調整消息的內容，或是模式的要求.在 Erlang進行模式匹配時往往有種約定：使用“原子”來表示“做什么”，而使用“綁定”來獲取操作所需要的“數據”，這種方式避免了冗余的cast和賦 值，在使用的時候頗為靈活.然而，世上沒有完美的事物，Erlang的消息執行方式也有缺陷，而且是較為明顯的缺陷.

首先，Erlang的數據抽象能力實在太弱.如果編寫一個略顯復雜的應用程序，您會發現程序里充斥著復雜的元組.您可能會疲于應對那些擁有7、 8個單元（甚至跟多）的元組，一個一個數過來到底某個綁定匹配的是第幾項，它的含義究竟是什么——一旦搞錯，程序便會出錯，而且想要調試都較為困難.因 此，也有人戲稱Erlang是一門“天生會損害人視力的語言”（令人驚訝的是，那篇文章居然搜不到了，我們只能從搜索引擎上看出點痕跡了）.

而我認為，這并不是Erlang語言中最大的問題，Erlang中最大的問題也是其“弱類型”特性.例如，現在有一個公用的Service Locator服務，任意類型的Actor都會像SL發送一個消息用于請求某個Service的位置，SL會在得到請求之后，向請求方發送一條消息表示應 答.試想，如果SL的功能需要有所修改，作為回復的消息結構產生了變化，那么我們勢必要修改每一個請求方中所匹配的模式.由于消息的發送方和接受方在實際 上完全分離，沒有基于任何協議，因此靜態檢查幾乎無從做起.一旦遇到這種需要大規模的修改的情況，Erlang程序便很容易產生差錯.因為一旦有所遺漏， 系統便無法正常執行下去了.

這的確是對于動態類型語言很常見到的擔心，而且，確實，如果不加注意會成為嚴重的問題.這種困擾確實是因為 Erlang 的“動態類型”和“基于消息”而造成的.但，這并非無解，實際上，在 Erlang 編程規范之中，已經給出了解決方案.

通常而言，Erlang 中的消息應該是以“控制流”為主，在消息的數據結構表達上，不同的消息通常都對應著不同的處理流程，在這里“控制”是消息中最為關注的內容.為此我們可以簡單的引入一個 atom 來予以表達，這就是 Tag Messages 的最佳實踐：

5.7 Tag messages

All messages should be tagged. This makes the order in the receive statement less important and the implementation of new messages easier.

Don’t program like this：

loop（State） ->

receive

...

{Mod， Funcs， Args} -> % Don‘t do this

apply（Mod， Funcs， Args}，

loop（State）;

...

end.

The new message {get_status_info， From， Option} will introduce a conflict if it is placed below the {Mod， Func， Args} message.

If messages are synchronous， the return message should be tagged with a new atom， describing the returned message. Example： if the incoming message is tagged get_status_info， the returned message could be tagged status_info. One reason for choosing different tags is to make debugging easier.

This is a good solution：

loop（State） ->

receive

...

{execute， Mod， Funcs， Args} -> % Use a tagged message.

apply（Mod， Funcs， Args}，

loop（State）;

{get_status_info， From， Option} ->

From ！ {status_info， get_status_info（Option， State）}，

loop（State）;

...

end.

可以相信，一段龐雜的代碼，在經過一番這樣對 Message 本身的設計和重構之后，最終都能讓其恢復“秩序與美感”.而消息中的其他參數，如果其處理邏輯非常復雜的話，那么帶有模式匹配的子函數，又或著是 Tuple/Record 正是其用武之地.

上面我們提到了“對 Message 的設計和重構”，實際上，這只是問題的一個方面.另外一個方面是：無論 Message 的“協議”設計得有多精巧，其對外的接口都不應該用消息來表達，而應該是“接口函數”的形式.

Erlang 系統之中的消息是極度靈活的系統，但它并不適合用來作為模塊之間的接口，因為它過于靈活.更加適合這一角色的設施是“函數”.用來充當這樣角色的函數就被 稱作“接口函數”，在其實現代碼中，除了“按照約定的格式發消息以外”什么別的也不做——因為它包裝的正是以消息為載體的交互“協議”.它是函數，有著嚴 格的語法檢查，而且可以在多個模塊之間重用.一旦需要修改消息協議，起隔離作用的“接口函數”就會體現出其存在的巨大價值.

5.10 Interface functions

Use functions for interfaces whenever possible， avoid sending messages directly. Encapsulate message passing into interface functions. There are cases where you can’t do this.

The message protocol is internal information and should be hidden to other modules.

Example of interface function：

-module（fileserver）.

-export（［start/0， stop/0， open_file/1， ...］）.

open_file（FileName） ->

fileserver ！ {open_file_request， FileName}，

receive

{open_file_response， Result} -> Result

end.

...code...

Erlang 是動態語言，對其進行靜態檢查比較困難（并非不能 R13 已經有所動作）.但，并不是說沒有靜態檢查就會寸步難行.Erlang 同樣重要的語法特性是它還是函數式語言，遇到有疑惑的地方，不妨以函數的角度來思考.

Erlang 語言素有“難學”的名聲，其中一個原因就是因為雖然其語法十分簡單，但常會讓人心生 “就這樣了，然后呢？” 之惑——因為過于靈活而無所適從，而且也不存在著顯而易見的正確用法.這種困擾通常要在有了一定的實踐經驗之后才會漸漸消散.換句話說，在“學會”和“用 好”之間存在著一堵模模糊糊的墻，而這一“未知區域”又需要一定的耐心和經驗方可穿越.