Erlang庫 -- 有意思的庫彙總

抄自這裏

 

首先，庫存在的目的大體可分爲：
一、提供便利
二、儘量解決一些痛點

首先，咱們先明確一下Erlang編程語言的一些痛點（僞痛點）：
1，單進程問題
Erlang虛擬機屬於搶佔式調度，搶佔式調度有不少好處，可是一樣也存在這弊端。虛擬機在默認狀況下分配個每一個進程的資源都是相同的，可是若一個進程（gen_server/event/fsm）要爲其餘許多進程提供服務，這個進程就極有可能成爲整個Erlang系統的瓶頸所在。http://www.cnblogs.com/--00/p/4277640.html
2，列表解析效率
在Erlang編程語言中，list/string 是很是常見的一種數據類型，list處理的方式幾乎都是遍歷或者是尾遞歸，在list規模小的狀況下，這種方式幾乎不會給你們形成麻煩，可是一旦list的規模很大以後，狀況就會變得很是糟糕。如list的「++」操做存在陷阱，erlang:length(List) 存在陷阱，queue:len(Queue)存在陷阱，諸如這種陷阱看起來很細碎，可是若是很差好處理，指不定就容易出現各類讓咱們摸不着頭腦的坑。
> 前不久，咱們剛剛在一個系統中，優化了一個lists:keydelete/3 的操做，大幅度提高了整個接口處理的速度。
固然，這些問題和erts的設計思路有很大的關係，如：private heap，變量不變 ... 。
3，refc binary
binary的存在在必定程度上緩解了list處理帶來的「低效率」的問題，可是，refc binary（erlang:byte_size(Binary) > 64的binary）的gc又讓人比較蛋疼。Erlang process structure -- refc binary
4，OOM
在必定程度上，這也是單進程問題的一個附屬品。單進程得到虛擬機資源有限，處理性能不足，致使message mail box 的message不斷擠壓，繼而引起large heap，致使整個Erlang 虛擬機crash。最最典型的就是lager了。
5，Erlang進程CPU消耗度量
一直以來，你們都在社區中試圖尋找度量單個Erlang進程CPU的消耗，可是不論是Erlang如今的API函數，仍是社區中的方案，都沒有提供一種行之有效的方案。爲何？我簡單摘抄一段Erlang_IN_Anger中的一段描述吧：
> It is generally difficult to properly analyze the CPU usage of an Erlang node to pin problems to a specific piece of code. With everything concurrent and in a virtual machine, there is no guarantee you will find out if a specific process, driver, your own Erlang code, NIFs you may have installed, or some third-party library is eating up all your processing power.



那麼，究竟有哪些庫，能幫咱們解決（或者是緩解）這些痛點，能給咱們帶來便利？
一、riak_sysmon
github : basho/riak_sysmon · GitHub
對erlang:system_monitor/0,1,2 的封裝，儘快的發現系統中存在的long_gc，large_heap等性能隱患。針對上述痛點中的「refc binary」和「OOM」。
二、recon
github : ferd/recon · GitHub
封裝了erlang:process_info/1,2 函數，並提供了TOPN的feature，recon_alloc封裝了度量虛擬機內部內存的使用量的查詢。
不只如此，recon提供了一種近似度量Erlang進程CPU消耗的方案，Erlang tool -- recon ，memory leak的檢查。針對上述痛點中的「Erlang進程CPU消耗度量」、「refc binary」，而且提供了種種便利。好用到爆的感受。
三、eper/redbug
github : massemanet/eper · GitHub
剛開始接觸Erlang時，社區提供的一種代碼調試方案是日誌。然，這種方式太不優雅，使用起來很是麻煩。
redbug是對Erlang系統中dbg模塊的封裝，提供了很是安全有效的代碼調試方式。「安全」對生產環境來講，確實太太重要了。
四、pooler/poolboy
github : seth/pooler · GitHub
github : devinus/poolboy · GitHub
池。Erlang單進程效率的問題，很是常見的三種方式，第一種是池，第二種是noblock call，第三種是修改某個進程的資源配置。
在社區中，常見的是第一種方案，而第二種和第三種方案常見於Erlang編程語言編源碼中（rpc模塊，net_kernel模塊）。針對上述痛點中的「單進程問題」。
五、jiffy
github : davisp/jiffy · GitHub
json處理庫，並且是nif的，可以儘量保證效果，而且能夠支持return_maps已經encode force_utf8，decode 的return_maps能直接返回map 數據類型，很是之方便。（雖然17的map效率不怎麼樣，可是18版本作了很大的優化）
六、entop
github : mazenharake/entop · GitHub
有沒有以爲Erlang自帶的etop有些難用？entop提供了很是不錯的可替代方案。
七、erlang-lz4
github : szktty/erlang-lz4 · GitHub
不論是Erlang系統，仍是其餘系統，所倡導的都是「小消息，大計算」，加之Erlang消息傳遞是值傳遞的方式，對於大的message，稍微作一下壓縮，獲取能取得意想不到的效果。不放試一試，lz4 的算法，請Google 之。

八、sync
github : rustyio/sync · GitHub
on-the-fly recompiling and reloading in Erlang. 大幅度提升工做效率，避免連續不斷的從新compile、generate。不過，要注意的是，最好只用在開發環境下。
> 關於熱更，多叨叨兩句：
> 1，在supervisor下增刪 gen_server child 熱更會失敗，目前無解，除非修改supervisor源代碼
> 2，gen_server record 增刪字段，這個可用 「使用proplists字段值」或者是「map字段值」
> 3，gen_server init 函數邏輯沒法熱更，解決辦法，重寫code_change 代碼
> 至於常規的邏輯代碼，熱更基本上沒什麼問題
九、erlang_term
github : okeuday/erlang_term · GitHub
存了一個Term到ETS表中，難道不該該知道這個Term到底佔用了多大的內存空間嗎？要send一個大的message給另外一個進程，不度量一點內存佔用大小就爲所欲爲？恐怕不太好。erlang_term能夠做爲貼心小工具。Erlang ets -- something about cache continue
十、folsom
github : boundary/folsom · GitHub
提供了多種Metrics 模型，根據本身的應用場景，選擇不一樣的模型就行。內部主要使用ets:update_counter/3,4，性能效果頗有保證。
十一、ej
github : seth/ej · GitHub
Helper module for working with Erlang terms representing JSON
試試就知道有沒有意思，好很差玩了。
十二、task
github : redink-toys/task · GitHub
遇到過這樣一個有意思的場景：主進程是一個普通進程，有10W量級的列表，我想將其過濾以後，將1/2或者是1/4的列表寫入到ETS表中，而後進行後續的操做。若是我在主進程中作這一些列操做，這個主進程就會被掛住，由於GC（Erlang的GC不會STW，但頗有可能會STP）。考慮到ETS表能夠在不一樣的進程之間共享數據，我就能夠在主進程中spawn一個進程，這個這個進程去執行過濾、寫入操做，而後這個進程生命週期結束以後，GC是很簡單快速的。
task就是一個spawn、receive的簡單封裝。
1三、xref_runner
github : inaka/xref_runner · GitHub
作xref檢查：善待Erlang 代碼 -- Xref 實踐

 

 

謝沒人邀。我只是來安利一下我司和我司兄弟公司開源的一些Erlang庫。如今使用Erlang的公司愈來愈多，可是你們都在閉門本身造輪子。咱們的原則是隻要有好輪子必定要好輪子，沒有好輪子本身輪一個好輪子。輪子大法好。

@redink 已經安利了好多在生產環境下很是好用的一些輪子，我再補充一些我司的替代品。

1. inaka/elvis – inaka/elvis · GitHub
Erlang代碼style檢查，支持github webhook，支持Erlang shell內運行檢查。另外inaka/erlang_guidelines提供了對初學者很友好的style guide，對一開始養成良好的代碼格式用處很大。

2. inaka/xref_runner – inaka/xref_runner · GitHub
跑xref的， @redink 已經安利過了

3. inaka/apns4erl – inaka/apns4erl · GitHub
久經考驗的iOS APNS推送服務

4. inaka/shotgun – inaka/shotgun · GitHub
對ninenines/gun的封裝，支持SSE (Server-sent Events) handling

5. inaka/worker_pool – inaka/worker_pool · GitHub
提供比poolboy更輕量的worker pool實現，支持多種worker輪轉策略

其中whisper1, tigertext, inaka是我司和友司的Github，歡迎圍觀，其中inaka是最有料的repo。

再安利一個Erlang Makefile - ninenines/erlang.mk · GitHub，雖然如今和一些項目不兼容並且功能還不完善，但和rebar相比，erlang.mk極大的提升了併發編譯的速度。換了Erlang.mk以後感受編譯速度快了幾倍。


說個坑。
benoitc/hackney · GitHub是個坑。Hackney是個坑。Hackney是個坑。雖然拼multi-part很好用，可是建議只使用hackney_lib裏提供的函數封裝，再使用別的http庫發。Hackney pool有不少不可復現的未知問題。

最後的最後，但願愈來愈多公司能夠開源生產級別的Erlang組件（玩具）。


P.S. 我在公司是個寫PPT的。若是須要內推我司在洛杉磯（Whisper\TigerText - 人須要在美國）、深圳、以及remote（Inaka）的工做請私信我。我司和友司都是業界前列使用Erlang分佈式特性的公司。（300+節點，多數據中心）

 

 

 

 

 

 

謝邀。廣告時間到了。 固然是extralib了。 change-code/extralib · GitHub

extralib的本意是一些質量略低於標準庫(kernel和stdlib)，可是從功能上講是目前標準庫所欠缺的功能，展現Erlang的潛力。

不少無腦黑認爲Erlang缺少metaprogramming能力，實際上Erlang是目前metaprogramming能力最強的語言。Erlang提供了parse_transform，還有隱藏的更深的core_transform。

更棒的是，如今在extralib裏，咱們引入了ext_syntax_trans，你可使用任意語法寫Erlang程序了，同時，還複製粘貼了一遍Erlang的parser，這樣，就能夠有scan_transform了。

如今就是來看看這個scan_transform有多大的威力了。在你的Erlang代碼里加入這麼兩行，在Erlang裏你就能夠有和Python同樣的Raw String了。 @牛耿

-compile({parse_transform, ext_syntax_trans}).
-compile({parser, {ext_epp, parse_file, [{passes, [ext_tokenline_pp, ext_rawstring_pp]}, {scan_options, [text]}]}}).

在有這個以前你是這麼寫正則表達式的

"\\r\\n\""

如今你能夠這麼寫了

r"\r\n\""

還不快來用Erlang