電子發(fā)燒友App
Erlang是什么？
Erlang編程語言最初目的是進(jìn)行大型電信交換設(shè)備的軟件開發(fā)，是一種適用于大規(guī)模并行處理環(huán)境的高可靠性編程語言。隨著多核處理器技術(shù)的日漸普及，以及互聯(lián)網(wǎng)、云計算等技術(shù)的發(fā)展，該語言的應(yīng)用范圍也有逐漸擴大之勢。
每一門編程語言的推出都是有目標(biāo)的。大多數(shù)的目標(biāo)是為了：提升性能，提升開發(fā)者表現(xiàn)力，提升開發(fā)者生產(chǎn)力，如Haskell，Python，Go等都是以這三點為主要設(shè)計核心的。
Erlang的推出則是為了打造一款高并發(fā)高擴展性的實時系統(tǒng)。例如應(yīng)用于電信，銀行，商業(yè)，即時通訊等場合。Erlang的運行時系統(tǒng)內(nèi)置了對并發(fā)，分布式，容錯等的處理?？梢娕c其它以速度，簡潔，表達(dá)性見長的語言相比，Erlang無疑就是只默默無聞的丑小鴨。
Erlang的容錯能力是它與生俱來的的能力，因為這是電信領(lǐng)域的重要需求。但是這并不代表Erlang是復(fù)雜的、不具表達(dá)力的。
語法
Erlang的語法是很簡單的，總共只有550行代碼。因此盡管erlang語法與主流語言比有所不同，但是掌握起來也是很輕松地。連貫性是它的亮點，請看如下代碼：
?
我們在erlang shell中執(zhí)行它
?
再來看一個復(fù)雜一點的代碼：
?
這個例子里使用了模式匹配功能，稍后再詳細(xì)講?，F(xiàn)在嘗試調(diào)用fac函數(shù)：
?
怎么樣？它的語法不復(fù)雜吧，我想只有Lisps可與之媲美簡單性。
表達(dá)性
當(dāng)說到Erlang表達(dá)性的時候，第一時間想到的可能是消息傳遞，過程創(chuàng)建和管理。然而這里的重點是模式匹配，特別是接收消息后，模式匹配可使其處理變得非常簡便。請相當(dāng)這個以下這個模式匹配的例子：
?
首先，我們想訪問Body和Headers變量。Shell提示的非常清楚：變量是非約束的。接下來嘗試做更有趣的。
復(fù)制之前的代碼后，接下來我們將會使用到http庫（ibrowse）：
?
然后執(zhí)行shell
?
回到之前的代碼里，
?
這里從ibrowse里調(diào)用了send_req函數(shù)。第一個參數(shù)是URL。第二場數(shù)是headers列表，即我們想發(fā)送的請求。在這里我們沒有發(fā)送任何的header。最后，第三個參數(shù)是我們指定的請求動作。
接下來看看其執(zhí)行結(jié)果：
?
其輸出是包含4個元素的數(shù)組，{Term1，…，TermN}。Erlang數(shù)組與Python數(shù)組是很相似的。第一個元素是“ok”信息，說明程序執(zhí)行正常。第二個元素是302，HTTP狀態(tài)碼302表示用戶被重定向。第三個元素是google返回給我們的headers結(jié)果。
?
接下來嘗試存儲該結(jié)果：
?
其運作過程是：我們發(fā)送了一個請求給google，然后google對此進(jìn)行響應(yīng)并返回結(jié)果。ok是一個原子，302是一個字符串。他們都沒有被指派，因為他們不是變量。但為什么這里使用了“=”號？原因在于Erlang中“=”號是作用不是指派。由于Erlang支持模式匹配機制，“=”在這里會作為匹配符來使用。它會嘗試尋找“=”號左右兩部分的共同點，然后把值與非約束變量進(jìn)行綁定，因此最后會把值指派到正確的變量。
所以從ibrowse得到的結(jié)果是：send_req，Erlang會認(rèn)為我們得到了一個以元素ok和302為開頭的一個四元數(shù)組。然后因為Headers和Body是非約束的，所以把Google返回的對應(yīng)內(nèi)容進(jìn)行指派。
?
也就是說，模式匹配是與它語言的switch或if/else/elif有著異曲同工之妙。
過程和消息
在函數(shù)式編程里函數(shù)的地位是舉足輕重的。他們可以被指派到變量，或是作為參數(shù)傳給其它函數(shù)或從其它函數(shù)里作為返回值返回。不妨把函數(shù)看作是其它類型。
?
在Erlang創(chuàng)建一個過程是很簡單的，這里使用了內(nèi)置的spawn函數(shù)進(jìn)行過程創(chuàng)建。
?
Spawn的作用是創(chuàng)建新過程并返回PID過程標(biāo)識。
?
如果你想針對消息進(jìn)行處理，而不僅僅局限于在shell中檢視結(jié)果，可以進(jìn)行如下處理：
?
這里創(chuàng)建了一個Echofun函數(shù)，作用是接收消息并顯示。
?
Erlang 適合做什么？
問題應(yīng)該是Erlang不適合做什么，而不是Erlang可以做什么。都是圖靈完整的語言，理論上你什么都能做，但是大多數(shù)人不會去拿Erlang開發(fā)操作系統(tǒng)，因為它不適合做這個。
那么，Erlang不適合做什么？
首先，數(shù)值計算。
Erlang是解釋型的，雖然現(xiàn)在的解釋器能夠編譯代碼，但是還是太慢。有些量化的軟件用Fortran寫的都需要算好久，換用Erlang會讓人等得想死。
再一個，業(yè)務(wù)邏輯非常復(fù)雜的系統(tǒng)。
這個說實話，Erlang真的不適合。Erlang最大的優(yōu)勢在于并發(fā)，以及并發(fā)系統(tǒng)的穩(wěn)定性。這就是為什么很多電信系統(tǒng)后端在使用Erlang。業(yè)務(wù)邏輯復(fù)雜之后，系統(tǒng)設(shè)計時分離并發(fā)模塊的時候就很難了，甚至有時候是為了并發(fā)而并發(fā)，這就沒有意義了。
Erlang特別適合做io bound的高并發(fā)服務(wù)器。Erlang最大的優(yōu)點就是輕量的線程，有極小的上下文交換（context switch）開銷。比如如下的一段代碼秒開100000個線程
［spawn（fun（） -> 0 end） || _ <- lists:seq（1， 100000）］。
鑒于這個特性Erlang很適合做服務(wù)器。有一些很好的框架比如Cowboy性能非常不錯。
Eric Moritz - Websocket Demo Results V2
現(xiàn)在越來越多的公司后端都開始嘗試使用Erlang，它還有其他一些優(yōu)勢。
對RPC良好的支持，提供了簡單高效的OTP框架幫助開發(fā)者快速實現(xiàn)功能
無間斷部署，運行時支持代碼交換。在Shell里一句make:all（［load］）無需重啟服務(wù)就更新代碼
在EC2和其他集群里簡單的部署
垃圾回收
酷炫的語法 - 一行怒解析tcp包
<<4:4， 5:4， ToS:8， ToL:16， Id:16， Flags:3， FlagOffset:13， TTL:8， 6:8， Checksum:16， SrcIP:32， DstIP:32， Payload/binary>> = X.
Erlang像任何其他一門語言一樣，當(dāng)然是什么都可以做。不過它更適合做邏輯比較簡單的服務(wù)端啦。
Erlang與Golang比較
我們都知道，無論是Python還是Ruby，甚至Java， 都是在解決業(yè)務(wù)層的問題，屬于應(yīng)用型語言，以解決業(yè)務(wù)邏輯為主，但還有一個領(lǐng)域是系統(tǒng)領(lǐng)域，偏網(wǎng)絡(luò)層和底層操作，在這一塊我一直在尋找一種優(yōu)雅的方案，C++被我首先給淘汰掉了，C的開發(fā)效率太低，Java倒是比較合適，就是太臃腫，而且缺少系統(tǒng)編程的基因，竟它是企業(yè)級開發(fā)出身的。
Erlang， 它在網(wǎng)絡(luò)層方面表現(xiàn)優(yōu)秀，同時容錯性和健壯性都很不錯，它的虛擬機是唯一可以跟JVM媲美的，而且還有OTP的超重量級武器，幾乎可以是通殺網(wǎng)絡(luò)層應(yīng)用，但根據(jù)我的總結(jié)它有一個硬傷和一個軟肋，這一點后面展開，可以說選擇Erlang是我目前所知道的方案里面是最優(yōu)的。
Golang其實也蠻早的，大概08年的時候就知道Google在搞一門奇怪的語言，之后的幾年一直有不少以老莫為代表的人在嘀咕Golang，其實我一直沒太關(guān)注，我從ROR中吸取的經(jīng)驗是，成熟度對于商用很重要，后來基于Golang開發(fā)的產(chǎn)品越來越多，讓我不得不去研究一下， 這我才知道，這就是我夢想中的Python，效率和性能達(dá)到了最佳的平衡，對Go了解越多， 就越不愿意用Erlang寫代碼，主要原因：
1、Erlang的硬傷在于代碼的可讀性、表現(xiàn)力，讓我來舉個小例子，比如你為你的系統(tǒng)軟件構(gòu)建一個RESTFUL的接口，我們大致了解一下代碼風(fēng)格， 用Erlang： https://github.com/extend/cowboy/tree/master/examples 用Go:http://code.google.com/p/goweb/wiki/GetStarted，先不說Erlang， 無論是你c/c++/python/ruby/java 出身， 對Go是不是有種很久違的感覺， 為什么說是硬傷？ 因為對一門語言來說，語法是不大可能會大幅度變更的， 而且不會出現(xiàn)大的變化， 我不知道有沒有人讀過《松本行弘的編程世界>，里面闡述的道理很明白， 真正好的編程方式是人去主宰計算機而不是計算機主宰人， 我感覺Erlang就有點主宰我的編程思維的感覺（我的視力本身就不好，它還在不斷的扼殺我的眼睛?。?， 編程首先是門邏輯學(xué)，其次是工程學(xué)，最后才是數(shù)學(xué)， 又讓我想起吳軍的《數(shù)學(xué)之美>所說的， 人工智能上個世紀(jì)一直在走彎路， 期望機器的高度圖靈完備， 而忽視人類本身已有的文明，統(tǒng)計歸納的應(yīng)用。
2、Erlang的軟肋在于高質(zhì)量的庫少，盡管有不少殺手級應(yīng)用， 同樣Go在這方面也是軟肋， 這一點對于一個不到五年的語言有情可原， 但對于一個20多年的語言是不是有點說不過去， 比如你用json解析庫，很多人都是從mochiweb這個基本不更新的庫中去抽取， 而我認(rèn)為對于類似json這種東西可以考慮融入到語言標(biāo)準(zhǔn)庫中， 因為未來的商業(yè)軟件的api化趨勢越來越明顯，說的難聽點 ， 一個倚老賣老一個與時俱進(jìn)，反正我對Golang的庫一點也不擔(dān)心， 目前的成績易經(jīng)非常棒了， 遠(yuǎn)遠(yuǎn)優(yōu)于Ruby/Python的前五年?！ ?br />
? ? ? ?3、Erlang不合群，這主要體現(xiàn)在跟其他語言的交互性上， 當(dāng)然這也有深層次的原因，Erlang本身有自己的哲學(xué) 如出錯恢復(fù)機制， 你融入一個其他語言的東西進(jìn)去，這帳就不好算，就好比你硬要讓一個喝咖啡的跟一個吃大蒜的坐在一起，總之你寫一個Erlang的port遠(yuǎn)遠(yuǎn)比Go復(fù)雜， 甚至比Python/Java還要復(fù)雜，這就造成了Erlang在底層編程上效果不是很好， 沒法利用linux已有的很多優(yōu)秀成果，我一直認(rèn)為Erlang的什么的mysql/pg/oracle驅(qū)動都沒有必要存在，Erlang一定是一個self-container應(yīng)用，你只要用到了其他東西， 根據(jù)木桶理論，你就不敢號稱9個9，以系統(tǒng)的眼光看問題，我覺得一個系統(tǒng)的魯棒性不能依賴于某一組件， 這也是為什么愛立信本身的Erlang應(yīng)用并不廣泛。
4、說說數(shù)據(jù)類型吧， 我不止聽到1個人說Erlang對字符串的處理不有好， 它把string當(dāng)做list來處理，其實本質(zhì)上是該這么，但，還是那句話， 違背了面向人的哲學(xué)， 應(yīng)該做一些DSL，比如Golang里面的 ：= 就是一個糖衣， 等價于 var xx yyy = zzzz， 大大方便的程序員少敲不少字符， Golang里面對字符轉(zhuǎn)可以說基本和python差不多，slice map函數(shù)很強大， 支持lambda條件，雖然Erlang的基本類型很少，但有很多構(gòu)造，所謂構(gòu)造等價于Golang里面復(fù)雜的struct， 也奇怪了，我就是感覺Erlang構(gòu)造傷眼睛好嗎？可能是各種括號的比對的原因吧， 而且我認(rèn)為這是不必要的， 顯然Erlang缺少DSL的基因， 當(dāng)然跟Erlang出身的年代有關(guān)， 我不夸張的說，自打用Erlang以后我的視力又下降了100度左右， 我不是很喜歡lisp所說的符號也是一種語法， 可能這又跟函數(shù)式編程有關(guān)吧：形式推導(dǎo)遠(yuǎn)大于邏輯演繹。
5、其實我最不關(guān)注的是性能問題， 因為隨著摩爾定律，單位計算單元的性價比會無限高，但Golang既然提出它的性能逼近C，那我還是提一下吧， 當(dāng)然，Erlang也還可以， 雖然比Java慢但跟Python一個檔次。
6、再談?wù)剤箦e機制， 因為Erlang的的報錯信息太讓人糾結(jié)了， 起初以為我不會看出錯信息， 后來也使用了Sasl， 還是不夠直觀，甚至有時要用工具分析crash文件來定位問題，還是跟Erlang的哲學(xué)有關(guān)， 在Erlang中一切都是并行的， 所以它根本不care是物理哪一行出錯， 只跟Actor綁定， 然后告訴你Actor的ID和出錯代號， 你自己憑經(jīng)驗去分析吧，這樣做的好處是可以很方便定位出并行中出現(xiàn)的問題，但凡事都是相對的， 在這一點上有點糾枉過正，根據(jù)我的經(jīng)驗， 絕大部分時候我只希望先給我明確的指出哪一行出錯了好嗎？ 甚至把順序的backtrace用完整的英文句子打印出來好嗎？至于并行中的錯誤及時在命令式多線程語言中是不常見的，雖然并不是沒有， 但遇到錯誤我再費勁去調(diào)試好了， 但并不是所有的邏輯都用并行的思維去定位問題， 我甚至認(rèn)為， 對于一個系統(tǒng)不完全是并行也不完全是串行，跟好比我們衡量世界不能單純的唯物也不能完全的唯心一樣， 這一點Golang就做了很好的折中， 不需要并行的時候你老老實實的寫串行代碼， 需要并行的時候也有較復(fù)雜的機制來應(yīng)對， 合乎情理。
7、再說說招人吧， 以前招過好幾個C出來的人，說實話水平很好， 可以一周就完成一個小組件， libevent用的熟的很，后來我逼人家用Erlang，結(jié)果把人家逼走了，至今我還很后悔， 自己的一廂情愿強加在別人身上真是太不合適了，但我招純Erlang出來的人，可以說比招objc的人還難， 沒有人，空談技術(shù)的優(yōu)雅性首先就是不靠譜的，再看看郵件列表， Golang的活躍度明顯比Erlang高很多，基本逼近Ruby，更重要的是，根本不擔(dān)心Golang的人才，因為只要熟悉Python/C/Ruby/或者C++， 基本可以實現(xiàn)半天入門， 之后就可以噼里啪啦邊搜資料邊干活了，雖然有足夠的深度，但門檻極其平緩，工程人員也可以復(fù)用很多已有的知識。 Erlang在這一點其實跟第一點硬傷有關(guān)，大部分人學(xué)一周都摸不著頭腦，不是每個人的抽象思維和世界觀都是一樣的好嗎， 所以函數(shù)式編程盡管不比命令式語言起步晚，但始終學(xué)的人很少，這就是歷史， 對于大部分人， 更希望解決問題，創(chuàng)造價值，而不是數(shù)學(xué)來推導(dǎo)去。?
8、最后我建議， 如果你是玩c/c++的， 現(xiàn)在開始學(xué)Golang，是最好的時機， 跟一門靠譜的語言一起成長， 這種感覺非常棒， 你用Erlang折騰1個應(yīng)用， 用Go恐怕都完成了10個開源項目， 當(dāng)然，也要結(jié)合自己的口味， Golang就是Sublime Text， Erlang就是Emacs相信自己的判斷，相信自己的邏輯。?
?
工商網(wǎng)監(jiān)
評論