以下是在erlang專案開發中的一些記錄，即包含很多通俗易懂的原則，也包含一些似是而非的建議，比較混亂，還沒有積累到乙個可以分門別類的地步，各位就將就看吧..
:)* 確保沒有任何編譯警告
* erlang中string採用list實現，32位系統中，其1個字元用8個位元組的空間（4個儲存value, 4個儲存指標)。因此string速度較慢，空間占用較大
* 在server中，總是盡力書寫尾遞迴(tail-recursive)的函式
* 使用'++'時，left list會被拷貝，然後新增到right list的頭部，因此最好把length較短的list放在左側
* 避免使用regexp，如果需要正規表示式，請使用re
* timer模組的大部分函式實現，依賴於乙個process，如果過多使用timer，會導致這個process負載過大，影響效率。
推薦使用erlang:send_after/3及erlang:start_timer/3
* 避免使用list_to_atom/1，因為erlang中atom數量最大為1048576, 且不進行gc控制。因此如果持續性的呼叫list_to_atom/1
可能很容易達到系統上限，從而導致emulator terminate。請使用list_to_existing_atom/1。
* list內部實現為乙個列表，因此length(list), 需要遍歷整個list比較耗時
* 對於不同的資料型別，使用不同的size函式：tuple_size/1, byte_size/1, bit_size/1
* 使用binary match來進行binary的分割，而不使用split_binary/2
* 如果兩個list都擁有很多資料，那麼請不要使用'--'，而是將資料轉化到ordsets，然後呼叫ordsets:substract/2.
* f(<>,...) ->
... % rest is not used here
f(rest,...);
f(<>,...) ->
... % rest is not used here
f(rest,...);
...
f(<<>>, ...) ->
returnvalue.
* 呼叫lists:flatten/1可以將list扁平化，這個操作代價很大，比'++'還要昂貴。下面這些時候我們可以避免：
將資料傳送給port時
呼叫list_bo_binary/1和iolist_to_binary前
* 小的函式可以讓您方便的找出錯誤的函式和**
* 不要在同一行出現相同的符號
20 some_fun() ->
21 l = [, ],
22 ...
編譯時，會提示line 21 '[' 語法錯誤， 因為21行有多個 '[' ，所以這個bug不能準確定位，你需要花時間去排查**。
好的做法是：
20 some_fun() ->
21 l = [,
22 23 ],
...這樣，編譯其會提示你 line 22 '[' 語法錯誤，你很開就知道是那個地方錯了。
* 使用 ctrl ＋ \ 或 init:stop()， 可以退出erlang， 使用ctrl ＋ g 及 ctrl + c 彈出選單選項，可以選擇是否退出erlang。
其中ctrl ＋ g可以用來連線其他的shell， ctrl ＋ c可以檢視其他一些系統資訊
ctrl + c abort 是野蠻的退出方式
* use "open_port(, [out])" make erlang program write standard error to unix system
* if you don't run experiments before you start designing a new system, your entire system will be an experiment!
* standard data structure desc:
module description
sets sets, i.e. a collection of unique elements.
gb_sets sets, but based on a general balanced data structure
gb_tree a general balanced tree
dict maps, also called associative arrays
ets hash tables and ordered sets (trees)
dets on-disk hash tables
suggestion：
elments count: 0 － 100 | 100 - 10000 | 10000 -
our select : list | ets | gb_tree
* 通過code:clash/0 檢測**中是否有module衝突現象（sticky)
* epmd -d -d 啟動 epmd 可以檢視erlang node之間的通訊
* 將正常的邏輯**和錯誤處理**分離，發生錯誤時，儘管錯誤。由另乙個錯誤處理模組進行處理
* 類似於作業系統，我們的程式也可以分為kernel 和 user 兩層， 對於kernel絕對不能出現錯誤， 對於user可以出現錯誤，進行恢復
* process頂層loop涉及的**及函式，最好在乙個module中實現
* process 的register name和module名稱一致， 便於尋找**
* 每個process具有乙個單一的角色，比如：supervisor 用來進行錯誤恢復， work 工作者，可以出現錯誤， trusted worker 不會出現錯誤
* 通過函式呼叫可以實現的功能，就不要使用sever實現（如gen_server, 及類似的loop 實現）
* 給訊息加乙個tag，在發生錯誤的時候，可以定位到訊息，同時也有利於程式的穩健
* 在訊息迴圈中，對於unknown的訊息，請呼叫lib:flush_receive/0 將其清除，減輕process msg queue的長度
* server中總是書寫尾遞迴的迴圈
* 盡量使用record， 而不是原始的tuple來表現資料結構， 在使用record時，使用select match：
#person = person
* 對於返回值，最好也新增乙個tag，用來說明返回值型別，或者執行成功與否
* 盡可能少的使用catch和try，在erlang程式中，不推薦主動捕獲異常。只有當我們的邏輯特別複雜，我們可以使用throw來返回資料，使用catch來獲取返回值。
* 當然程式與外界互動，外界資料不可靠時，需要使用catch和try
* 慎重使用process dictory， 當你使用get/1, put/1時，你的應用會具有很大的slide effect。可以通過加入乙個新的引數來儲存原本需要儲存到process dictory中資料
* 如果不想使自己糊塗，請不要使用import
* 使用export時，將功能類似的介面組合在一起，並新增合理的注視，這樣你的介面更清晰，別人使用起來更方便
* 不要書寫巢狀太深的**
* 不要書寫太長的module
* 不要書寫太長的函式
* 每行**不能太長
* 避免使用 "_" 匿名變數，請為每個變數選擇有意義的名稱，如夠某個變數暫時不使用，請以下劃線 "_" 開始
* enfile error in socket 是以為內linux系統中 ulimit 限制， 在root下修改：ulimit -n 25000
* 表示socket已經關閉
* 在erlang開發時，慎重使用macro，因為erlang的single assign的緣故，同時呼叫某個marco，而macro又定義了某個變數，可能導致badmatch錯誤。
比如：-define(addlineinfo1(f),
(begin
str1 = lists:concat(["[mod:", ?module, " line:", ?line, "]"]),
str1 ++ f
end)).
-define(warn(log, f, d), log4erl:warn(log, ?addlineinfo(f), d)).
如果連續使用 warn, 會出現此錯誤
* erlang中可以定義很多環境變數：
erl_max_ets_tables 設定最大的ets數目 預設1400
erl_max_ports erlang最大的port數目 預設1024
順序如下
okok
* 任何時候，都要重視函式的返回值，通過match確保您的預期，如果發生錯誤，那麼就大膽的表達出來。
Erlang開發建議
以下是在erlang專案開發中的一些記錄，即包含很多通俗易懂的原則，也包含一些似是而非的建議，比較混亂，還沒有積累到乙個可以分門別類的地步，各位就將就看吧.確保沒有任何編譯警告 erlang中string採用list實現，32位系統中，其1個字元用8個位元組的空間 4個儲存value,4個儲存指標 ...
erlang雜記十二 再說尾遞迴
翻了一下list模組，看的時候，突然發現，尾遞迴其實是很容易展開成迴圈的。想起讀書時剛開始學程式，c語言，一直再糾結的乙個問題，就是如何讓乙個函式返回兩個引數的結果，哈哈，不要笑我。do sth sa,sb do sth ha ta la,hb tb lb,sa,sb do sth ta,tb,ha...
Erlang遊戲開發 協議
erlang 百科 協議包含通訊協議和資料格式.通訊協議目前常用的是 http和tcp.其有各自的特點根據遊戲的特點而進行選擇.http比較成熟,使用極其廣泛.具有豐富的基礎軟體和工具.對於簡單的social game可以使用http作為通訊協議.這類遊戲對實時性要求不是很高,使用http也很容易做...