速度變身高大上程序員快來學Erlang吧！參與討論獲好禮（獲獎名單已公布-2014-8-29）

ciscopuke

craaazy123 發(fā)表于 2014-07-16 14:13
rabbitmq,  couchdb，愛立信的電信系統(tǒng)，whatsapp的后臺 etc.

好像是哦，最初的erlang的一個布道者就是來自愛立信吧，這些大公司就是牛逼啊，總能孕育出這些牛逼的玩意出來

crazyhadoop

回復 24# cokeboL


    換個思路學習一下也不錯的，你可以感受一下函數(shù)式語言的姿勢！

cokeboL

回復 31# crazyhadoop


    恩恩，以后有時間再研究，我先面向產(chǎn)品和職業(yè)方向?qū)W習

bluejing0

Erlang本身的一些機制的不足
1.        運行時record 的問題，
Record 在erlang中并不是一個運行時可見的數(shù)據(jù)結(jié)構(gòu)。代碼中所有對record的變量的賦值，讀取等操作全部會轉(zhuǎn)化為對tuple的element的操作。這種形式帶來了無窮無盡的麻煩：主要是在產(chǎn)品升級的時候。我們的電信產(chǎn)品一般會要求6個9，即：99.9999%的穩(wěn)定性，和0 downtime。即：升級的過程中不允許有電話打不通的時間。如果某個record在版本升級中結(jié)構(gòu)變化了，而不允許有downtime意味著大量的進程要有能力處理舊的和新的record，一不小心就crash給你看。
這個問題我跟OTP team討論過無數(shù)次了，他們也沒有很強的想法在這上面，beam文件本身已經(jīng)包含了record的相關(guān)信息不知道為什么不肯做一個簡單的實現(xiàn)。
現(xiàn)在我們的實現(xiàn)方法是在運行時反編譯自己，獲取record的信息進行操作。但這個要求編譯的時候要帶debug作息，而且cookie一旦泄漏，源代碼很容易被反編譯出來。
在OTP R17中引入了一個新的數(shù)據(jù)類型，叫做MAP，類似于JSON的數(shù)據(jù)結(jié)構(gòu)，它與record相比做了質(zhì)的變化：運行時可見了，并且可隨意添加成員變量。這無疑是對record這種舊的數(shù)據(jù)結(jié)構(gòu)的另外一種演化方向。我很喜歡這種變化。但是我們同時也不得不考慮軟件維護的成本：不可能僅僅是為了使用這種數(shù)據(jù)結(jié)構(gòu)而把原來的上百W行代碼重寫。所以個人而言，我還是希望能有一個運行行的record，例如把record轉(zhuǎn)化為map，并且兼容對record的操作方式，并在幾個release內(nèi)慢慢淘汰record這種數(shù)據(jù)結(jié)構(gòu)。
2.        字符串的處理，
字符串在erlang中一直是個弱點。
包括正則表達式。在很多語言中正則表達式本身是做為一種特殊的數(shù)據(jù)類型存在的，比如用//包住，在erlang中，RE本身是做為字符串處理的，而字符串和RE都有轉(zhuǎn)義的問題，要匹配一些特殊字符就要進行多次轉(zhuǎn)義，非常惡心，比如用"\\\"去匹配 "\"。如果要匹配多個這樣的字符，那寫出來的正則表達式簡直無法入眼。
另外，字符串的處理效率也是個問題。字符串在erlang本來是以Lists存在的，雖然有個string的庫，不管說它豐富不豐富，效率就是個問題。

3.        運行效率的問題，雖然R17已經(jīng)有了LLVM backend，但是效率還是不夠。而且HIPE本身存在的問題也很多，有很多莫名其妙的bug。而HIPE本身年紀太大， 很多想法已經(jīng)太out。
LLVM的效率的確不如HIPE，在LLVM的performance test中可以看其效率與原來的HIPE基本持平。但是好處是LLVM是開源的工具鏈，其做為backend穩(wěn)定性應(yīng)該會比HIPE強。在烏不撒拉大學的原來的HIPE主頁上，感覺終于把HIPE趕走了可以松一口氣了。R17的release notes中也認為LLVM HIPE可以做production usage.

4.        mnesia問題。mnesia效率實在太差，差的都不想吐嘈了，現(xiàn)在完全成為了系統(tǒng)的瓶頸。
Mnesia本身一般不會存儲用戶數(shù)據(jù)，一般只是一些配置數(shù)據(jù)。在我們的產(chǎn)品中大約有幾百張表，每個表一般只有幾條到幾十條不超過上百條記錄。即便這樣，mnesia已然不堪重負，嚴重的成為了系統(tǒng)的瓶頸。
5.        同時Mnesia為SNMP做了很多優(yōu)化，但是這些優(yōu)化很多時候限定了mnesia data schema本身，這種綁定有時候不但不會帶來收益，會帶來很多問題。
6.        調(diào)試工具實在太爛，有時候很容易把自己卡死。我后來不得不改了他們的源代碼，沒事別亂打印，wx太慢，一打印大數(shù)據(jù)結(jié)構(gòu)就卡死了。
如果有一個更好的調(diào)試的庫就更好了。
7.        dbg:tracer只能trace MFA 或者msg, 遠遠不到完善的地步。
需要一個更好的dbg的庫。
8.        to_erl環(huán)境變量的問題，跟OTP的人們說過，他們堅決不改。
但是其實這個很簡單，可以考慮做個工具，在用戶用to_erl連接到VM的時候把用戶的一個ENV（如display） apply一下，只要不影響運行中的程序就可以了。
9.        兩個site連接起來之后不能立即通信，要sleep一會兒。
我搜索了好久，仍然搞不清楚erlang是如何解析和連接node()的。
10.        文檔不健全，很多文檔語焉不詳，要必須跟OTP的人聊過或看過代碼之后才明白。 從如描述smp的那一大段。
11.        沒有bench mark的工具
12.         OTP升級不夠平滑。每次換OTP都心驚膽顫。

q1208c

回復 33# bluejing0

這位兄弟看來是真正的高手, 原來erlang中有這么多問題.

對于 OTP的升級, 小弟雖然沒有在生產(chǎn)中用過, 但發(fā)現(xiàn)每次更新
都有一堆新的問題. 真不敢想, 這貨也能做到 7個9 . 不知道那
要多少個節(jié)點才頂住得. 還必須有非常良好的架構(gòu).


不過, 對于 record, 小弟以為, 為什么要去動record的結(jié)構(gòu)呢?
在record的一個字段里動不是更好? 有點類似 數(shù)據(jù)庫 的一維表.


小弟新學, 還沒入門, 還請兄弟多多指點.

bluejing0

to: crazyhadoop
是的。

bluejing0

回復 34# q1208c


    record就跟class一要，偶爾添加幾個成員是很正常的操作。在生產(chǎn)環(huán)境中真是天天見。

q1208c

回復 36# bluejing0

我覺得這個問題就跟數(shù)據(jù)庫一樣. 經(jīng)常有人要增加字段. 但誰都知道, 對于一張很大的表, 如果增加字段. 是個很耗時的操作, 有時候, 還有風險.


   

shenlanyouyu

Erlang不懂，頂一下活動。

it5186

幫頂！在學Erlang程序設(shè)計——PDF的，書可以給一本嗎？