扯淡 erlang 的“适合”和“不适合”

现在在体系内大力推广erlang了。不过挺遗憾的是，推行 erlang 前并没有对这个语言自身进行深入的论证和研究，只是由核心人员写了一个简单得不能再简单的 demo，在项目里用了一个开源的 erlang 项目。从工程的角度来说，这是不靠谱的，为了让 erlang 的使用更加靠谱，所以在这里扯淡一下。资料来源于erlang官方和我的猜测，对不对由我，信不信由你。

先看来自 erlang FAQ的内容（自己随手翻译的，不一定准确，可看原文：http://www.erlang.org/faq/introduction.html#1.3）：

——————————————————

1.3 Erlang 特别适合使用的项目是什么？

分布式的，可靠的，软实时并发系统。

* 电信系统，例如控制交换或者协议转换

* Internet应用服务器，例如邮件传输代理，IMAP-4 服务器，HTTP 服务器，WAP栈

* 电信系统，例如处理移动网络的切换或者发布统一格式的消息。

* 需要软实时功能的数据库应用

Erlang 在最初设计时有明确的处理问题的范围，所以 Erlang 在处理一些问题时会有很好的表现。下面有一些该类问题的特征描述：

* Erlang 提供了简单并且有效的异常控制和容错机制（受监管的进程）。

* 并发和消息传递是语言的内建机制。使用 Erlang 编写的应用通常保持数百甚至数千轻量进程。Erlang 进程的上下文切换的开销，比 C 程序的线程一般要少一到两个数量级。

* 开发运行在不同的设备上的应用（例如分布式应用）变得容易。Erlang 的分布式算法是透明的：程序不需要知道他们是分布的。

* OTP 库提供了许多网络和电信系统的一般功能的支持。

* Erlang 运行时环境（一个虚拟机，类似 Java 的虚拟机）意味着代码“一次编译，到处运行”。同时，运行时系统也允许在不中断程序执行的前提下对正在运行的系统进行更新。

===========================
1.4 Erlang 不是特别适合使用的项目是什么？

令人惊讶的是用户在所有可能的地方使用 Erlang，一个例子是在协议级别同 X11 通讯，但是，一些情况下 Erlang 并不是应该被选择的语言。

最常见的“不太适合”的问题是性能需求是最主要的，并且客观因素对性能有极大影响。有代表性的例子是图像处理，信号处理，排序大量数据和底层协议中断。

另一个类别的问题是大量涉及 C 代码。有代表性的例子是实现操作系统设备驱动。

多数（全部？）使用 Erlang 开发的巨型系统，可能在底层代码上大量使用 C，离开 Erlang 去管理在其他语言中倾向于复杂的部分，如控制系统在数个机器上的分布和实现复杂的协议逻辑。（这个翻译有疑问，到底是在这种情况下不要用 Erlang，来由自己实现呢？还是交由 Erlang 来管理呢？）

——————————————————

如果我没理解错，FAQ透漏出一个信息：Erlang 的目标主要是用在大规模通讯这类应用上。对于高并发的数据流I/O应该是不错的选择（例如网关、数据交换等）。而对于复杂的业务逻辑处理或高性能的数值计算并不在行（如游戏中的游戏逻辑）。

不过我这里有一份很旧的文档（看时间应该是 2006 或 2007 年的）显示，使用多语言混合的 Erlang 应用，效率可能还不如纯的 Erlang 应用。主要原因是 Erlang 的轻量进程的切换开销，要远小于同其他程序通信时造成的进程切换开销。

好吧，扯淡了这么多，上点猛料。内部推广 erlang 的时候，并没有这些资料，不过我觉得很有意义：

一个基于 erlang 的 MMO 引擎：http://sunweaver.blogspot.com/

编写基于 erlang 的 MMO 服务器：http://www.devmaster.net/articles/mmo-scalable-server/

一个基于 erlang 的 MMO 架构：http://www.next-gen.cc/

由上面的 MMO 架构引出的讨论：http://news.ycombinator.com/item?id=981597

另一个关于 erlang 在 MMO 应用的讨论：http://www.blitzbasic.com/Community/posts.php?topic=75515


哦，对了，另外推荐个材料，关于 go 的：http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_project

go应该说从某些方面弥补了 erlang 的短板……

2月28日补充：

Tim 已经很好的做了一个关于C（nginx）、Erlang、Java 和 Go 的测试：http://timyang.net/programming/c-erlang-java-performance/ 测试很完整，不过后面的 comments 更精彩！如果体系内有人能够在推广新东西的时候，做一些类似这样有说服力的工作就好了。

另外，在 Tim 的 comments 中有人给出了这个东西 http://www.javaeye.com/topic/107476 虽然是好多年前的了，但也很有价值。

不过个人切以为，当然好的语言能够如虎添翼，但是就现有项目期望的并发和负载量，语言选择绝对不是技术上的瓶颈本质……呵呵……

3月2日补充：

旧文一篇：http://www.javaeye.com/news/3510-joel-reymont-of-complaints-erlang

这个文章本身没什么，里面的一些观点和思想可能在这么多年后也有更新，不过评论里有个朋友说得非常好：“没有将一个游戏系统很好的分成不同的子系统，他那样的作法，无论使用哪种语言，到最后系统扩展起来，都会有很多的麻烦”，“在系统规划上没有足够的经验，或者说没有足够调查分析”，“使用ＯＯ的思想做ＥＲＬＡＮＧ，就是一个方向性的错误，erlang是不支持ＯＯ的”。

这位朋友的评论，正好说出了我们已经犯了的，或者正在犯的，甚至将要犯的错误！！！

3月3日补充：

今天在地铁上看着涌上、涌下的人群，我突然顿悟：对于即不关心架构，又要求性能。即不懂 worker、perfork，又要求多核的他们来说。的确！Erlang是最好的选择。甚至是唯一的选择！

3月7日补充：

强大的python，一个用 python 实现的 erlang 节点：http://www.lysator.liu.se/~tab/erlang/py_interface/。哦，对了，在对 erlang 整体研究过后，发现体系内需要的其实不是 erlang 这个语言，而是 erlang 这个架构。也就是需要一个面对程序员透明的分布式计算的架构，呼……