Erlang-China

最近比较活跃的 Erlang 社区事件是 Scalaris 的代码公布以及 火热的 json BIF 讨论。

Scalaris 就是我们在上一篇中提到的 Alexander Reinefeld 在 Erlang eXchange 2008 上展示的神秘的 Yet An Other Key-Value DB 项目。目前它的源码已经“全文公开”的 host 在 google code 上了，在 [这里] 还有一份 pdf 的 Slide 可以看，比起其他的两个项目，其特色是：

All In Memory 数据存储在 gbtree 中 —— 目前还没有提供存储到磁盘的特性。
实现了N多传说中的算法。比如，用来在 P2P 的 DHT 网络中寻址的 Chord 算法 和用来进行数据备份的 Paxos 算法。

据说代码写得相当清晰，极具学习价值。(默念10遍： OpenSource 就是好，就是好，就是好来，就是好)。

另外一件事就是 Joe 老爷爷最近提出了一个 EEP (Erlang Enhancement Process —— Erlang 的特性增强过程，类似于 Java 的 JCP) 要增加一个 Json <--> Term 的 BIF (内建函数)。确实也该如此，现如今 Json 大有称霸江湖的意思，Erlang 的世界里也已经有了 N 多个版本的 Json <--> Term 库，我至少已经领教过 4 个不同的版本了，每个库的 spec 都“略有不同”，颇有些“各自为战，谁都不爽”的意思。推出一个受到广泛认可的 BIF 无疑能够让这个世界立马变得清静许多。

说实话 Json <--> Term 乃至在语法之中直接加入 Json 的支持都算不上是什么难事，但相比由 OTP Team 在下一个版本的 Erlang 中静悄悄的加入某个 BIF 的“独裁”方式， EEP 无疑会是一个更社区化的过程。也就是说，它必然会经历 “提案，方案，辩论，投票” (或类似)的民主化过程，很多时候，这会很“乱糟糟”和“低效”。不过，这些代价绝对能值回票价 —— 最终我们会得到一个无论是在效率还是 API 上都更优秀的 Json <--> Term BIF 。除此之外，对于广大的使用者而言，这个[ “辩论”和“争吵”]的过程，也富有营养 —— 我们不仅(将会)知道最终的方案是什么，还能知道这个方案是怎么来的(比如说，它 PK 掉了哪些其他方案，它们存在着什么样的问题)，这一切就发生在眼前。

misc

etorrent 是最近相当活跃(常能在 maillist 见到 ann )的一个项目，它是用 erlang 实现的一个 bittorrent 客户端。记得刚刚接触 erlang 的时候就觉得它貌似很适合用来写 bittorrent 客户端(分布式/TCP/并发)，深入了解一番了之后，又觉得比起 C 来 erlang 并没有太明显的优势(GUI/CPU Heavy/IO/File)，加之后来见到堪称完美的 uTorrent 横空出世(说实话，除了网上银行，唯一想让我回到 windows 平台的东西就是它了)让人不再有动力作“写 torrent 客户端”之想，没想到时隔一年，还真见到了这样的项目，让人感慨。现在的 etorrent 已经是第二个公开发布的版本了，从它的 change log 看到，特性增强很厉害，以“ 20 个 torrent 占用 50－80M 内存”这样的指标来说，已经相当接近实用水平了。或许日后的 etorrent 再配上一个好用的 frontend 能够打造出像 xmms2 那样强大的软件也说不定呢。

log4erl 是一个 log4* 的 erlang 实现。对于广大习惯了 log4* 的 erlang 使用者来说，确是一个福音。不过，从某种程度上讲，这也可以算是某种“重复建设”—— erlang 自身已经内置了相当强大的日志机制。注意，只是强大，我并没有说易用。因为对于广大 log4* 爱好者们而言，只有能使用 grep/awk/perl 这些标准 unix tool chain 来处理的，格式化的，每条一行的(问题是，以我的经验来说，”每条一行”这种限制常常会逼人多费半天劲，或者多写一大堆)才是易用的日志。而 erlang 自身内置的日志机制说实话也毫不逊色，只是用来颇有一些不同(加之文档组织得别出心裁，让人不易找到)，各自属于不同的风格。既被拔到了“风格”层面，也就参杂了情感因素，无法以简单的方式来区分高下(君不见 csdn 上 x vs y 的口水仗层出不穷无休无止?)。本是见仁见智的事，大家看个人的喜好各取所需就是了。

顺便说说 erlang 自身的日志机制，极简的例子看上去象这样：

这好比是 log 的配置文件，然后，这样用：

这样，在 debug.log 里面就有了：

差不多就是这样了，更多配置，相关工具，以及更 “The Erlang Way” 的用法，可以参看文档 SASL 的部分。

btw，升级 wp 时从 incoming link 里发现一个 “默默无闻的领悟Erlang传说” 的中文 blog ToQuick (图快?)，主人 cheng 同学治“程”(程序)态度严谨，细密，文章写得勤也写的好，值得推荐。下面对于 log4erl 的代码观感就转自图快：

log4erl代码非常精简，保持了erlang代码的风格，log4erl包括1个supervisor和2个gen_server和1个gen_event。
log4erl.erl为gen_server和application behaviour的callback，其作为主要的module，
log4erl_sup.erl为supervisor,启动log4erl,初始时将通过log4erl_sup:add_file_logger启动default_logger 日志记录器。
log4erl_sup:add_file_logger/1会动态添加file_logger_guard和file_logger两个child process。

have fun.

misc

自从 Amazon 的 Dynamo 横空出世，开源的 Erlang 的 Key-Value 存储机制(毕竟有一些区别，因此我并不愿意把这个东西称作数据库)似乎已经成为了一个炙手可热的研究领域。先是有 CouchDB (本站多次介绍，已经被 apache 接纳的开源项目)，现在又有了 Kai 。如果算上 Alexander Reinefeld 在 erlang exchange 2008 上展示的项目，很短的时间之内，这一领域已经产生了三个 open source 项目了，可谓进展神速。

说起来，这个新出的 Kai 乃与是我们“一衣带水”的日本同行们的作品。加之此前听说的 Orto，以及零星听说的具有超强并发能力的 tokyocabinet，等。老实说，对于他们在 opensource 领域所表现出来的整体活力，确实有些惊讶。可惜不懂日文，未能对此作进一步的了解。(召唤日语达人整理一下)

话说这几个项目共同关注的是一个相同的问题，然而各自的侧重又略有不同。比如说，Kai 项目实现的乃是(又是) memcache 的访问接口和协议，主要侧重在利用 Erlang 来提升系统在“分布和容错”方面的特性。而 couchDB 则首先关注于实现 key-value 的数据存储本身，在此基础上建立完全不同于 RDBMS 的查询机制，并以优雅的 RESTful 访问接口而著称(Alexander 的项目资料不多，尚不明朗)。应该说是各有特色，而且具有很好的互补性，实在让人很难在这两者之间进行取舍。所以当 couchDB 团队的 Jan Lehnardt 向 Kai 团队的 Takeru Inoue 提出 Collaborate 的建议时，对于广大使用者而言，确实是最为“喜闻乐见”的情形。

或许我们很快就能见到 CouchDB Powered Kai 又或者是 Kai Powered CouchDB，两个项目的特性得到融合，也许，两者之间会形成一种如同 innoDB 之于 mysql 那样的合作关系，谁知道呢？未来充满可能，值得我们期待。开源的 Erlang 就是这么精彩。

news