在 CouchDB 狐狸书 中，作者 Jan Lehnardt 描述了一种全新的 Web 开发模式，有这样一句话来形容这种新的开发方式。

CouchDB has changed the way I think about developing web applications

在有着 10+ 年 Web 开发经验的我看来，尤其是在确实理解了他们心目中的开发方式之后，我觉得，这并不是一句阿谀奉承的面子话。而是，实事求是地说 —— 完全没有夸张的成分。

我在这里极其“概略”的介绍一下这种匪夷所思开发方式的若干基本要素：

1. CouchDB 是一个 NO-SQL 的“文档数据库”，以 B-Tree 提供 Powerful 的数据存储与访问能力
2. CouchDB 是追加型数据库，其内部以 MVCC 机制管理每个文档的不同版本
3. CouchDB 采用了一种没有中心节点的架构设计，数据可以以数据库为单位，在多个 CouchDB 节点之间互相同步，数据同步时，也用 MVCC 来保证数据同步的一致性
4. CouchDB 以 Http Restful 的方式对其中存储的文档提供最基本的 CRUD 接口，也就是说能够直接以 Ajax 方式使用这些接口
5. CouchDB 实现了服务端逻辑的扩展机制，即，可采用 JavaScript (也可以用其他语言)定义 View ，这个 View 会在 Server 端以 Map-Reduce 方式来运行，中间结果也被 B-Tree 保存，当数据变化时，只需重新 Map 此条数据即可保持同步。也就是说，一旦 View 定义好，查询结果就已经准备好了，取用之时，无须计算
6. 上述逻辑扩展机制的“服务端代码”也被储存在一类特殊的文档之中，简而言之，这些“服务端代码”在绝大部分的情况下，都可以被当作“普通数据”来对待，尤其是，同样可以在节点之间同步
7. 文档可以带附件，想带多少带多少，想带什么带什么，随便带，没限制。比方说，Browser 客户端会用到的 HTML、CSS、脚本、图片什么的

PS. 上面描述的这些正处在迅速的进化之中……包括身份验证，同步过滤，URL Mapping 等等，所有需要用到的一切，正在迅速被增加进来。

已经呼之欲出 —— CouchDB 将会进化成为一个 AppServer！虽然还处在非常早期的阶段，仍然缺少拼图的一些重要部分，但我们已经可以大致的窥见这头犀利 AppServer 的一些只鳞片爪。

• 服务端脚本 —— 纯 JavaScript 开发环境
• 特殊文档 —— Web 应用本身就是一个文档
• 程序同步 —— 一键安装 Web 应用
• 数据同步 —— 离线 Web 应用
• ……

基于前面提到要素，不难组合出更多妙不可言的特性来，对于日益得到重视的 JavaScript 程序员们而言(实际上，其他程序员也是一样，只是，稍微没有那么“显而易见”而已)，未来是一件多么值得期待的事？

这是“求素数”的 Java 代码。基本来自 dachidahu 的帖子，为了测试方便，略做修改。

这是相应的 Erlang 源代码。顺手写的。实际包含三个分支，略有区别。其中的 a 分支是严格按照 java 版本的逻辑逐行翻译写出来的。 b 和 a 的唯一区别是在递归当中加入了一个列表参数 L 来传递计算结果。c 分支则采用 dachidahu 同学的“优化思路”——用已经求出的素数来作为被除数，以降低运算次数。

作为基准，先看 Java 的版本表现如何：

看看 Erlang 三个分支各自的运算表现：

结果有没有让你吃惊？

分支 a 与 java 代码几乎是严格对应的，执行的性能比 java 略慢一点(慢30%)，但差别很有限，并没有得出象 dachidahu 同学那样离谱的差异。

分支 b 和分支 a 的唯一区别是多加了一个参数用来传递当前已经算出的素数。仅仅多了这么一步，和前面一个分支相比，立刻就有了非常惊人的差别(慢1133%)。

分支 c 则正如我们预料的一样，要比分支 b 快一点点。但也仅仅只是比 b 快了那么一点点而已(快6%)。

通过这个例子，我们能够体会到 Erlang 怎样的性能特性呢？

1. Erlang 并不以高效著称(它最为突出的特性应该是可靠性，其次是基于消息的彻底隔离与内置的分布式支持)，虽说 Erlang 团队在虚拟机优化上下了很多功夫，但比起同样经过“业界精英苦心优化”的 Java 来说，可能仍然是各有千秋(具体怎么个各有千秋法，仍需仔细考察)。至少在这个例子中 Erlang byte code 并没有在实际执行中表现出超越 Java byte code 的性能。
2. 和上面一条恰好相反，Erlang 的虚拟机也并不像我们所想象的那么糟糕，有文章称 Erlang 虚拟机比 Java 虚拟机要慢上一个数量级，我不知道这样的结论是如何得出的，但至少在上面这个例子中的 rem (整除)操作上，并没有看到这样的差异。
3. 虽说列表操作在 Erlang 语法里看起来只是一句超简单的“原子操作”，但实际上它也是有代价的。尤其是，当需要承载大量数据的时候(有文章称超过 1K 数据量就应该考虑其他数据结构)，就不再适合采用 list 来装数据。
4. 类似于 list 的例子，在 Erlang 里可能还有不少。具体会怎样，应该靠实际而耐心的测试去发现问题，而不是我们的猜测。要点就是，这是不同的语言，之前的经验或许已经不再适用。
5. 不要提前(草率)优化。优化是一个精细活，必须建立在精细设计的 profiling 的基础之上，找出瓶颈，然后再优化之。否则，就会象上面的 c 分支一样，优化了半天，却根本就没有击中要害。

我们以一个 trick 来结尾，在 Erlang 里面是否有超越 Java 执行性能的可能呢？有！比如说，我们可以象这样：

不错吧。

不过，这是以 native code 对 byte code 的怪招，胜之不武。哈哈。

-EOF-

其实 Port 对 Erlang 而言是一个很重要的扩展设施。在 Disco，在 CouchDB，在很多重量级的 Erlang 项目中，我们都能看到 Port 的使用。在大量的 Erlang 项目实战中，最初的快速原型开发确定之后，再将发现的瓶颈部分改为更加高效的本地 Port 来实现(如果能够确认这样的实现真的更加高效的话)，这似乎也是比较通行的做法。放在这样的应用场景下考虑，此时的 Port 其实充当着“ Worker 调用者”的角色，而 Erlang 自身则变成了动态机器集群的“粘合系统”。与“将一个机房/一堆机器当作一台机器来使用”的架构目标达成了极佳的重合。

对于大多数的 Erlanger 而言，在实际的工程实践中，对“效率”和“适用性”上的考量应该被放在第一位，对“是否纯粹”的执着则应该被看得更淡一些。

最近“老赵”同学写了一篇《一种适合C# Actor的消息执行方式(上)》，其中提到“(在消息执行上) Erlang 中最大的问题”。这是一个很有意思的观点，而且因为富于代表性因而显得很有价值，很有必要拿出来和大家探讨。

其中提到：

Erlang的优势与缺陷

　　Erlang在消息执行方式上的优势在于灵活。Erlang是弱类型语言，在实现的时候可以任意调整消息的内容，或是模式的要求。在 Erlang进行模式匹配时往往有种约定：使用“原子”来表示“做什么”，而使用“绑定”来获取操作所需要的“数据”，这种方式避免了冗余的cast和赋值，在使用的时候颇为灵活。然而，世上没有完美的事物，Erlang的消息执行方式也有缺陷，而且是较为明显的缺陷。

　　首先，Erlang的数据抽象能力实在太弱。如果编写一个略显复杂的应用程序，您会发现程序里充斥着复杂的元组。您可能会疲于应对那些拥有7、 8个单元（甚至跟多）的元组，一个一个数过来到底某个绑定匹配的是第几项，它的含义究竟是什么——一旦搞错，程序便会出错，而且想要调试都较为困难。因此，也有人戏称Erlang是一门“天生会损害人视力的语言”（令人惊讶的是，那篇文章居然搜不到了，我们只能从搜索引擎上看出点痕迹了）。

　　而我认为，这并不是Erlang语言中最大的问题，Erlang中最大的问题也是其“弱类型”特性。例如，现在有一个公用的Service Locator服务，任意类型的Actor都会像SL发送一个消息用于请求某个Service的位置，SL会在得到请求之后，向请求方发送一条消息表示应答。试想，如果SL的功能需要有所修改，作为回复的消息结构产生了变化，那么我们势必要修改每一个请求方中所匹配的模式。由于消息的发送方和接受方在实际上完全分离，没有基于任何协议，因此静态检查几乎无从做起。一旦遇到这种需要大规模的修改的情况，Erlang程序便很容易产生差错。因为一旦有所遗漏，系统便无法正常执行下去了。

这的确是对于动态类型语言很常见到的担心，而且，确实，如果不加注意会成为严重的问题。这种困扰确实是因为 Erlang 的“动态类型”和“基于消息”而造成的。但，这并非无解，实际上，在 Erlang 编程规范之中，已经给出了解决方案。

通常而言，Erlang 中的消息应该是以“控制流”为主，在消息的数据结构表达上，不同的消息通常都对应着不同的处理流程，在这里“控制”是消息中最为关注的内容。为此我们可以简单的引入一个 atom 来予以表达，这就是 Tag Messages 的最佳实践：

5.7 Tag messages

All messages should be tagged. This makes the order in the receive statement less important and the implementation of new messages easier.

Don’t program like this:

loop(State) ->
  receive
    ...
    {Mod, Funcs, Args} -> % Don't do this
      apply(Mod, Funcs, Args},
      loop(State);
    ...
  end.

The new message {get_status_info, From, Option} will introduce a conflict if it is placed below the {Mod, Func, Args} message.

If messages are synchronous, the return message should be tagged with a new atom, describing the returned message. Example: if the incoming message is tagged get_status_info, the returned message could be tagged status_info. One reason for choosing different tags is to make debugging easier.

This is a good solution:

loop(State) ->
  receive
    ...
    {execute, Mod, Funcs, Args} -> % Use a tagged message.
      apply(Mod, Funcs, Args},
      loop(State);
    {get_status_info, From, Option} ->
      From ! {status_info, get_status_info(Option, State)},
      loop(State);   
    ...
  end.

可以相信，一段庞杂的代码，在经过一番这样对 Message 本身的设计和重构之后，最终都能让其恢复“秩序与美感”。而消息中的其他参数，如果其处理逻辑非常复杂的话，那么带有模式匹配的子函数，又或着是 Tuple/Record 正是其用武之地。

上面我们提到了“对 Message 的设计和重构”，实际上，这只是问题的一个方面。另外一个方面是：无论 Message 的“协议”设计得有多精巧，其对外的接口都不应该用消息来表达，而应该是“接口函数”的形式。

Erlang 系统之中的消息是极度灵活的系统，但它并不适合用来作为模块之间的接口，因为它过于灵活。更加适合这一角色的设施是“函数”。用来充当这样角色的函数就被称作“接口函数”，在其实现代码中，除了“按照约定的格式发消息以外”什么别的也不做——因为它包装的正是以消息为载体的交互“协议”。它是函数，有着严格的语法检查，而且可以在多个模块之间重用。一旦需要修改消息协议，起隔离作用的“接口函数”就会体现出其存在的巨大价值。

5.10 Interface functions

Use functions for interfaces whenever possible, avoid sending messages directly. Encapsulate message passing into interface functions. There are cases where you can’t do this.

The message protocol is internal information and should be hidden to other modules.

Example of interface function:

-module(fileserver).
-export([start/0, stop/0, open_file/1, ...]).
 
open_file(FileName) ->
  fileserver ! {open_file_request, FileName},
  receive
    {open_file_response, Result} -> Result
  end.
 
...code...

Erlang 是动态语言，对其进行静态检查比较困难(并非不能 R13 已经有所动作)。但，并不是说没有静态检查就会寸步难行。Erlang 同样重要的语法特性是它还是函数式语言，遇到有疑惑的地方，不妨以函数的角度来思考。

感谢 Arbow 的分享。感谢 JeffreyZhao 的写作。

Erlang 语言素有“难学”的名声，其中一个原因就是因为虽然其语法十分简单，但常会让人心生 “就这样了，然后呢？” 之惑——因为过于灵活而无所适从，而且也不存在着显而易见的正确用法。这种困扰通常要在有了一定的实践经验之后才会渐渐消散。换句话说，在“学会”和“用好”之间存在着一堵模模糊糊的墙，而这一“未知区域”又需要一定的耐心和经验方可穿越。

“Erlang 是动态类型的语言，因而不能进行静态分析，所生成的文档也不包含有助于理解的类型信息”——这是惯常的看法，广为流行，而且被看作是 Erlang 在开发大型系统时的一个短板(大型系统意味着更强烈的静态分析需求和更严重的依赖文档进行沟通)。

然而 Erlang 是一个有着 20 多年历史的成熟系统，它早已发展出了一套自己的类型标注系统，不仅用来生成文档，更重要的是可以据此对源码进行静态分析，通过程序来排除一些低级的和隐藏的错误。在这方面， Erlang OTP 的源码本身及其文档就是最好的例子。在 《Erlang 程序设计》 的附录A部分，对于这个系统的使用已经进行了充分的说明。

需要强调的一点是在 Erlang 语言的背后还有一个活跃的社区(后者更为重要)，其 EPP 过程一直都在持续不断地推进语言本身的进化。这方面最新的成果便是：在 R13 中，将此前文档级的 @spec，@type 标注升级为语言级的 -spec，-type 标注。可以预期的一点是，在未来的版本中，这些方面仍将持续推进。

litaocheng 同学的这篇“Erlang类型及函数声明规格”，风格严谨，论述详尽，涵盖了最新的语言特性，是任何一个程序员想要开发“严肃 Erlang 程序”的必读文档。

Erlang类型及函数声明规格

Author: litaocheng
Mail: litaocheng@gmail.com
Date: 2009.6.8
Copyright: This document has been placed in the public domain.
Contents: