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