Erlang-China

对不住，仍然是 JavaScript 的消息， 并不是我存心要改行播报 JavaScript 新闻，而是这条实在太重磅，不报不合适了都。

刚刚还在[上一篇]的回复中数落 FireFox 不务正业地搞什么“多脚本语言支持”，而不去专心加速 JavaScript 的运行。貌似这句话现在我就得自己吞回去了。因为 John Resig 同学博了一篇关于 FireFox v3.1 之中的 TraceMonkey 技术，加速约7倍！这一消息表明 FireFox 内部在 JavaScript 上的投资仍然保持了足够的“密度”。

TraceMonkey 基于 trace tree 理论。是一种 JIT [Just In Time] 优化技术。简单地说，JIT 就是在“合适的时候”（也就是 Just In Time 的要义）将 JavaScript 编译为 native code 再来执行（Java 很早就已经采用 JIT 来提升性能了）。而 trace tree 则对这些 native code 再做进一步的化，比如：优化函数调用，优化类型检测，优化循环，等等。据称，在多项性能测试之中，开启了这一特性之后，脚本的运行性能有了“惊人的”提升。有图为证：

而，这一特性在 nightly build 的 FireFox v3.1 中已经就绪，只需下载，安装，并在 about:config 中打开选项：

即可立即开始体验。

顺便八卦一句：FireFox v3.1 的脚本引擎仍然还是 SpiderMonkey，TaceMonkey 只是 SpiderMonkey 的一个版本代号，它有很多代码都是来自于 Adobe 捐赠的 Tamarin 引擎，看来这只猴子的消化力的确很强。

另外八卦一句：打了鸡血的 SpiderMonkey 已经显著超越了 SquirrelFish 的性能。

misc

你们一定注意到了——除了 Erlang 之外，这里还充斥着大量的 JavaScript 文章。是的，我喜欢 JavaScript ，我从不掩饰这点。实际上，我一直都是 “Dead Hard” 的 “Web Fundamentalist”（“死硬”的 “Web 原教旨主义者”），我固执（并孤独）的认为面对 “应用全面 Web 化” 的未来，要写出能适应 “爆炸性增长曲线” 的下一代软件（比如象最近老是崩溃的 twitter，不需要 “爆炸” 的软件不在此讨论的范畴之列，比如，给小企业迅猛的做一个百十来人用的系统赚点零花钱），业界所需的 “NEXT BIG ONE” 语言就是 Erlang ，但毫无疑问，它有很多缺陷，同样不能包打天下（基本上，任何声称自己能够包打天下的东西，都很可疑）。比如说，其中很致命的一条就是——在 Client 端的 Erlang 就像是当年的 Java Applet 一样，表现拙劣(几乎可以说是一无是处)。但是借助 HTTP/Ajax/REST/JSON 这一系列标准，或者干脆就说是 HTTP/HTML/JavaScript 的力量，则刚好可以绕过这些限制，而且还有点符合潮流的意思。这么说吧 —— JavaScript 和 Erlang 应该成为一对搭档。

不过 JavaScript 这个搭档之前出了一些状况。简单来说，就是：
[以下内容，纯属文学演义，如有雷同，纯属命名冲突，各大公司，纯属不对号入座]
Read more…

misc

distributerl 是最近 google code 上 open 的一个项目，在它的介绍中这样写道：

Building blocks for Erlang/OTP systems using distributed algorithms.
……
Coming soon: generic versioned objects for convenient use with Merkle trees
Coming a bit later: Generic Gossip Protocol

它提供了：Vector clocks, Consistent Hashing, Merkle Trees 这几种分布式算法的 Erlang 实现。此外它还将会提供 Gossip Protocol。

老实说，对于这种后面标有引用论文的算法，我一向都是相当景仰的(也就是说，基本不懂)。在此强烈召唤达人现身，科普一二。但这几个名词的出现频率有猛增的趋势(比如 scalaris 的 pdf, amazon s3 的宕机说明，等等)，因此仍然引起了我的注意。现在的情形似乎是 —— 要是不懂这些大词，看见别的搞“分布式”的，你都不好意思上去打招呼。反正俺是准备知耻而后勇的上去 wikipedia 啃一下英文的了。

与此同时，在 maillist 中也有人正在讨论 Erlang 的 Design Tool。非常好，因为这个问题我已经找了很久，但并未找到答案，若有高人现身说法解我疑惑，那就再好没有了。

关于 design 的问题，我也顺便 blah 一下(当前版本)感想，：

1. 在 Erlang 设计中 UML 的协作图比较好用，能够帮忙理清思路。好多工具都已经“进化”到不再支持这种不是那么 OO 的非主流图型了，如果找不到合适的工具，试试相当老旧的 borland together architect 吧。

2. 用 Erlang 写东西，设计上仍然需要精心设计 API ，也仍然需要在“对象”(或曰进程)“生命周期”的设计决策上浪费大量“生物 CPU”时钟。在这一点上 Erlang 也好 Java 也罢，彼此之间其实并没有太多差别。当然 otp 的 application 或者 gen_xxx 实际上已经在扮演“生命周期管理者”的角色。但，毫无疑问，它的“接口”设计并不怎么“性感”，望之常常让人有“#$@!%*”之感。我在想，是不是也该有个像 Spring for Erlang 这样的东西，把所有“对象”的“生命周期”给管起来呢？

building block for distribute 的通用项目，以及 design tools 的讨论，表明开发者们正在越来越认真的对待 Erlang 语言，这或许也表明大家正从“学习”阶段向“扩大再应用”的阶段转换。

misc