用erlang也算寫了些代碼了，主要包括使用RabbitMQ的練習，以及最近寫的kl_tserver和icerl。其中icerl是一個實現(xiàn)了Ice的erlang庫。
erlang的書較少，我主要讀過<Programming Erlang>和<Erlang/OTP in Action>。其實erlang本身就語言來說的話比較簡單，同ruby一樣，類似這種本身目標是應用于實際軟件項目的語言都比較簡單，對應的語法書很快可以翻完。
這里我僅談談自己在編寫erlang代碼過程中的一些感受。
語法
erlang語法很簡單，接觸過函數(shù)式語言的程序員上手會很快。它沒有類似common lisp里宏這種較復雜的語言特性。其語法元素很緊湊，不存在一些用處不大的特性。在這之前，我學習過ruby和common lisp。ruby代碼寫的比common lisp多。但是在學習erlang的過程中我的腦海里卻不斷出現(xiàn)common lisp里的語法特性。這大概是因為common lisp的語法相對ruby來說，更接近erlang。
編程模式
erlang不是一個面向對象的語言，它也不同common lisp提供多種編程模式。它的代碼就是靠一個個函數(shù)組織出來的。面向對象語言在語法上有一點讓我很爽的是，其函數(shù)調用更自然。erlang的接口調用就像C語言里接口的調用一樣：
func(Obj, args)
Obj->func(args)
即需要在函數(shù)第一個參數(shù)傳遞操作對象。但是面向對象語言也會帶來一些語法的復雜性。如果一門語言可以用很少的語法元素表達很多信息，那么我覺得這門語言就是門優(yōu)秀的語言。
表達式/語句
erlang里沒有語句，全部是表達式，意思是所有語法元素都是有返回值的。這實在太好了，全世界都有返回值可以讓代碼寫起來簡單多了：
Flag = case func() of 1 -> true; 0 -> false end,
命名
我之所以不想寫一行python代碼的很大一部分原因在于這門語言居然要求我必須使用代碼縮進來編程，真是不敢相信。erlang里雖然沒有此規(guī)定，卻也有不同的語法元素有大小寫的限定。變量首字母必須大寫，atom必須以小寫字母開頭，更霸氣的是模塊命名必須和文件名相同。
變量
erlang里的變量是不可更改的。實際上給一個變量賦值，嚴格來說應該叫bound，即綁定。這個特性完全就是函數(shù)式語言里的特性。其帶來的好處就像函數(shù)式語言宣揚的一樣，這會使得代碼沒有副作用(side effect)。因為程序里的所有函數(shù)不論怎樣調用，其程序狀態(tài)都不會改變，因為變量無法被改變。
變量不可更改，直接意味著全局變量沒有存在的意義，也就意味著不論你的系統(tǒng)是多么復雜地被構建出來，當系統(tǒng)崩潰時，其崩潰所在位置的上下文就足夠找到問題。
但是變量不可改變也會帶來一些代碼編寫上的不便。我想這大概是編程思維的轉變問題。erlang的語法特性會強迫人編寫非常短小的函數(shù)，你大概不愿意看到你的函數(shù)實現(xiàn)里出現(xiàn)Var1/Var2/Var3這樣的變量，而實際上這樣的命名在命令式語言里其實指的是同一個變量，只不過其值不同而已。
但是我們的程序總是應該有狀態(tài)的。在erlang里我們通過不斷創(chuàng)建新的變量來存儲這個狀態(tài)。我們需要通過將這個狀態(tài)隨著我們的程序流程不斷地通過函數(shù)參數(shù)和返回值傳遞下去。
atom
atom這個語法特性本身沒問題，它就同lisp里的atom一樣，沒什么意義，就是一個名字。它主要用在增加代碼的可讀性上。但是這個atom帶來的好處，直接導致erlang不去內置諸如true/false這種關鍵字。erlang使用true/false這兩個atom來作為boolean operator的返回值。但erlang里嚴格來說是沒有布爾類型的。這其實沒什么，糟糕的是，對于一些較常見的函數(shù)返回值，例如true/false，erlang程序員之間就得做約定。要表示一個函數(shù)執(zhí)行失敗了，我可以返回false、null、failed、error、nil，甚至what_the_fuck，這一度讓我迷惘。
list/tuple
erlang里的list當然沒有l(wèi)isp里的list牛逼，別人整個世界就是由list構成的。在一段時間里，我一直以為list里只能保存相同類型的元素，而tuple才是用于保存不同類型元素的容器。直到有一天我發(fā)現(xiàn)tuple的操作不能滿足我的需求了，我才發(fā)現(xiàn)list居然是可以保存不同類型的。
list相對于tuple而言，更厲害的地方就在于頭匹配，意思是可以通過匹配來拆分list的頭和剩余部分。
匹配(match)
erlang的匹配機制是個好東西。這個東西貫穿了整個語言。在我理解看來，匹配機制減少了很多判斷代碼。它試圖用一個期望的類型去匹配另一個東西，如果這個東西出了錯，它就無法完成這個匹配。無法完成匹配就導致程序斷掉。
匹配還有個方便的地方在于可以很方便地取出record里的成員，或者tuple和list的某個部分，這其實增強了其他語法元素的能力。
循環(huán)
erlang里沒有循環(huán)語法元素，這真是太好了。函數(shù)式語言里為什么要有循環(huán)語法呢？common lisp干毛要加上那些復雜的循環(huán)（宏），每次我遇到需要寫循環(huán)的場景時，我都誠惶誠恐，最后還是用遞歸來解決。
同樣，在erlang里我們也是用函數(shù)遞歸來解決循環(huán)問題。甚至，我們還有l(wèi)ist comprehension。當我寫C++代碼時，我很不情愿用循環(huán)去寫那些容器遍歷代碼，幸運的是在C++11里通過lambda和STL里那些算法我終于不用再寫這樣的循環(huán)代碼了。
if/case/guard
erlang里有條件判定語法if，甚至還有類似C語言里的switch…case。這個我一時半會還不敢評價，好像haskell里也保留了if。erlang里同haskell一樣有guard的概念，這其實是一種變相的條件判斷，只不過其使用場景不一樣。
進程
并發(fā)性支持屬于erlang的最大亮點。erlang里的進程概念非常簡單，基于消息機制，程序員從來不需要擔心同步問題。每個進程都有一個mailbox，用于緩存發(fā)送到此進程的消息。erlang提供內置的語法元素來發(fā)送和接收消息。
erlang甚至提供分布式支持，更酷的是你往網絡上的其他進程發(fā)送消息，其語法和往本地進程發(fā)送是一樣的。
模塊加載
如果我寫了一個erlang庫，該如何在另一個erlang程序里加載這個庫？這個問題一度讓我迷惘。erlang里貌似有對庫打包的功能(.ez?)，按理說應該提供一種整個庫加載的方式，然后可以通過手動調用函數(shù)或者指定代碼依賴項來加載。結果不是這樣。
erlang不是按整個庫來加載的，因為也沒有方式去描述一個庫（應該有第三方的）。當我們調用某個模塊里的函數(shù)時，erlang會自動從某個目錄列表里去搜索對應的beam文件。所以，可以通過在啟動erlang添加這個模塊文件所在目錄來實現(xiàn)加載，這還是自動的。當然，也可以在erlang shell里通過函數(shù)添加這個目錄。
OTP
使用erlang來編寫程序，最大的優(yōu)勢可能就是其OTP了。OTP基本上就是一些隨erlang一起發(fā)布的庫。這些庫中最重要的一個概念是behaviour。behaviour其實就是提供了一種編程框架，應用層提供各種回調函數(shù)給這個框架，從而獲得一個健壯的并發(fā)程序。
application behaviour
application behaviour用于組織一個erlang程序，通過一個配置文件，和提供若干回調，就可以讓我們編寫的erlang程序以一種統(tǒng)一的方式啟動。我之前寫的都是erlang庫，并不需要啟動，而是提供給應用層使用，所以也沒使用該behaviour。
gen_server behaviour
這個behaviour應該是使用頻率很高的。它封裝了進程使用的細節(jié)，本質上也就是將主動收取消息改成了自動收取，收取后再回調給你的模塊。
supervisor behaviour
這個behaviour看起來很厲害，通過對它進行一些配置，你可以把你的并發(fā)程序里的所有進程建立成樹狀結構。這個結構的牛逼之處在于，當某個進程掛掉之后，通過supervisor可以自動重新啟動這個掛掉的進程，當然重啟沒這么簡單，它提供多種重啟規(guī)則，以讓整個系統(tǒng)確實通過重啟變成正常狀態(tài)。這實在太牛逼了，這意味著你的服務器可以7x24小時地運行了，就算有問題你也可以立刻獲得一個重寫工作的系統(tǒng)。
熱更新
代碼熱更新對于一個動態(tài)語言而言其實根本算不上什么優(yōu)點，基本上動態(tài)語言都能做到這一點。但是把熱更新這個功能加到一個用于開發(fā)并發(fā)程序的語言里，那就很牛逼了。你再一次可以確保你的服務器7x24小時不停機維護。
gen_tcp
最開始我以為erlang將網絡部分封裝得已經認不出有socket這個概念了。至少，你也得有一個牛逼的網絡庫吧。結果發(fā)現(xiàn)依然還是socket那一套。然后我很失望。直到后來，發(fā)現(xiàn)使用一些behaviour，加上調整gen_tcp的一些option，居然可以以很少的代碼寫出一個維護大量連接的TCP服務器。是啊，erlang天生就是并發(fā)的，在傳統(tǒng)的網絡模型中，我們會覺得使用one-thread-per-connection雖然簡單卻不是可行的，因為thread是OS資源，太昂貴。但是在erlang里，one-process-per-connection卻是再自然不過的事情。你要是寫個erlang程序里面卻只有一個process你都不好意思告訴別人你寫的是erlang。process是高效的（對我們這種二流程序員而言），它就像C++里一個很普通的對象一樣。
在使用gen_tcp的過程中我發(fā)現(xiàn)一個問題，不管我使用哪一種模型，我竟然找不到一種溫柔的關閉方式。我查看了幾個tutorial，這些混蛋竟然沒有一個人提到如何去正常關閉一個erlang TCP服務器。后來，我沒有辦法，只好使用API強制關閉服務器進程。
Story
其實，我和erlang之間是有故事的。我并不是這個月開始才接觸erlang。早在2009年夏天的時候我就學習過這門語言。那時候我還沒接觸過任何函數(shù)式語言，那時候lua里的閉包都讓我覺得新奇。然后無意間，我莫名其妙地接觸了haskell（<Real World Haskell>），在我決定開始寫點什么haskell練習時，我發(fā)現(xiàn)我無從下手，最后，Monads把我嚇哭了。haskell實在太可怕了。
緊接著我懷揣著對函數(shù)式語言的濃烈好奇心看到了erlang。當我看到了concurrent programming的章節(jié)時，在一個燥熱難耐的下午我的領導找到了我，同我探討起erlang對我們的網游服務器有什么好處。然后，我結束我了的erlang之旅。
時隔四年，這種小眾語言，居然進入了中國程序員的視野，并被用于開發(fā)網頁游戲服務器。時代在進步，我們總是被甩在后面。