出处： http://erlang-china.org/misc/scalaris_and_build-in-json.html
近比较活跃的 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 掉了哪些其他方案，它们存在着什么样的问题)，这一切就发生在眼前。