有趣的 Erjang 项目
Kresten Krab Thorup 是一位有着 20 多年程序设计语言实现经验的大牛。
I have been doing language implementation for 20 years. I was at NeXT doing the Objective-C compiler for some years in early-mid 90’s. I have worked on severa rounds of gcc, the GNU Objective-C, the palmos-m68k port, the JVM interpreter inside GNU Compiled Java. I have also contributed little pieces to JRuby, and a ton of other language stuff.
貌似是一位靠谱程度相当之高的同学。他在 GitHub 上设立了一个 Running Erlang On JVM 的项目 —— Erjang，到目前为止，已经达到可以顺畅运行 RingTest 的完成度，有兴趣的同学可以 git clone git://github.com/krestenkrab/erjang.git 弄回来玩一玩。Erjang 的大致设计思路是：
It loads Erlang’s binary .beam file format, converts it into Java’s .class file format, and loads it into the JVM. It will eventually have it’s own implementation of all Erlang’s BIFs (built-in-functions) written in Java. Those are being implemented as I stumble upon them in testing.
当然了，这是“终极目标”，当前实现版本的状况是：
Right now Erjang relies on an external Erlang process to utilize some of the beam handling code in the standard library (e.g., so I don’t have to parse .beam files), but Erjang would eventually be able to self-host the required modules. Right now, Erjang also uses jinterface to talk to other Erlang nodes, but that will needs porting/rewriting, I think.
稍有常识的技术人员都知道，如果不是过过嘴瘾的话，这样的“终极目标”将会意味着多大的工作量，但是有 20年+ 专业经验值的牛人通常都是非常 unpredictable 的物种。因而，这些工作对他而言到底需要多少时间，确实也很难说。
我知道，看到这样的项目，和我一样，第一反应，你肯定也会产生这样的疑问 —— Erlang 的 BEAM 已经是一个有着相当长时间历史的成熟 VM ，在很多方面都已经做了高度优化，为其他 VM 所不及；而 Erlang 在 Language 和 VM 的配合上也颇多好评，为人称道。那么，Kresten 这么做又有什么必要呢？
实际上，这个问题在 Reddit 上确实也引来了一大堆激烈的争论。Kresten 本人为此单独写了一篇 Erjang, Why? 来讲述自己的观点，有兴趣了解的朋友可以点[这里]延伸阅读。以下是我的 blah ，不喜欢 blah 的同学可以直接略过。
对于我个人而言，似乎还看不见 Erjang 的实用意义(说不定是因为我短视呢)。
但，无论如何，人家牛人 Kresten 同学既然都已经做出来了，总归也不会是一件坏事。 JVM Team 好歹也是 20年+ 以上大量开发团队的智慧结晶，必有过人之处，两相对照，肯定能发现一些 BEAM 团队没有考虑到的地方。通常而言，一个语言出现多个实现，彼此互相对照和竞争，绝对是一件好事。比如说，在 Kresten 的 blog 中就已经提到，它在 fib 的测试上发现 BEAM 在 bignum 的运算表现上不如 JVM 的好。
除了这些“整体上”的好处，Erlang 在 JVM 的实现，想必会也受到 JVM 体系固有的限制，如果因而破坏语言本事的一些核心特性，比如，进程的独立性，GC的独立性之类的，那么在具体选择时，就值得我们这些使用者再三斟酌了。
———-我是分隔线————-
顺便要抱怨一下。今天点 Firefox 地址栏里的 RSS 图标想要直接订阅 Kresten 的 blog ，发现 fusion.google.com 居然也被该死的功夫网给墙了，纯粹一个工具，能颠覆什么？这帮魑魅魍魉怎么就怕成这样了？
大家大多都有翻墙经验，随便设置一下就好了。但是，其他人怎么办？一个这么好的功能，就这样被这些破玩意给糟蹋了，凭什么？想来都让人上火。希望大家和我一样，多向身边的人传播翻墙技巧。日拆一砖，就不信丫能在世界的东方永远屹立不倒。
感觉jvm上面很难高效的实现 user thread， 这会不会影响Erjang的效率呢？
这个倒不见得是必然，技术上，没有什么东西是不可能的。JVM 本身也在进化，比如，这篇文章(http://bluedavy.com/?p=4)之中就提到了 Java 上的 Coroutine 实现貌似效率也很好的样子。
或许 JVM 上也能做出效率很高的 Erlang 实现也不一定，我所关注的只是 Erjang 能否和 Erlang 保持语义和基本特性（尤其是容错特性）上的一致性。
Erjang uses Kilim [http://bit.ly/aGtxqF] which is a co-routine facility for Java, with surprisingly good performance. Kilim does a kind of CPS transformation(Continuation Passing Style) for Java byte code, thereby allowing “plain” Java code to participate in a cooperative co-routine scheduling. The references at the bottom of the Kilim website has some performance data. There’s also an independent report on Kilim here http://bit.ly/cmJenn
@Kresten Krab Thorup
Hi, Kresten. Thanks for reply.
Kilim 是很强大的 Java Coroutine 实现，不仅如此，其他的语言其实也大都各自有了自己的“轻量级”进程实现库，甚至 BSD 的一大分支 DragonFly 都已经在把“轻量级”进程做到 Kernal 里了。以此为基础，用一堆“轻量级”进程来做事情，再整一个 Schedule 出来管理这些进程，再配上一些“外围设施”，写出这样的系统已经不再需要“火箭科技”了，从理论上来说，这和“The Erlang Way”或者“COP”也已经差别不多。Kresten 做的 Erjang ，还有 xushiwei 他们的 CERL 与其 inspire 的源头 Erlang 相比，从这个“更底层”(How things Work)的角度来说，可能并没有太大的区别。
然而，语言又是另外一个问题——语言决定了我们如何思考(和交流)，交流的本质归根结底还是思考，要建立在用大脑这个“超级工具”对“对方”进行“某种模拟”的基础之上。如果说我们说话所用的语言是“人-人接口”，那么程序设计语言就是“人-机接口”，换句话说，它是建立在“人脑怎样去模拟一台电脑”的基础之上的。是“寄存器-运算指令-内存”？还是“指针-数据结构”？又或者是“对象-线程-锁”？再或者是“进程-消息”？从计算机语言的进化序列来看，每一种重要的新语言都有自己对于“计算机模型”的独到改进，当然了，这里是以一门新问世语言对计算机编程模型的“贡献”而言。有些语言因为具有相当的“可塑性”，因而能够很方便的借鉴其他语言的思想，不断为原有语言注入“新概念”，但这并不是我们这里正在讨论的重点(在 Lisp，C，Pascal 的发展过程我们都能见到这一点)。
Erlang 的“贡献”就是“COP”(面向并发编程)——它打破了人们对于进程的固有想象，并使得“以大量采用进程的方式来构建和模拟现实场景”的编程思想为人们所知(Joe 老头还一并挑战了传统 OOP 中“继承”的观点，认为进程才是“对象”合理的运行时抽象模型，更符合朴素的 OO 定义)。在此之后 Scala、Clojure、Erjang、CERL…… 这些后来者都开始在各自的领域践行这一理念。它们或者是在既有的基础之上创立一个新语言，或者是将这些特性引入已有的语言之中，又或者是在另一个虚拟机上实现 byte code 级的兼容运行。老子曰“道生一，一生二，二生三，三生万物”，计算机世界的道，似乎也在以这样的方式衍化运行。
对语言的好恶，大概是个永远也别想有答案的“口味”问题。正如 JQuery 和其他的 JS 库，大家做的事情其实没啥区别，然而 JQuery 却俨然就是一种“新的方言”，它所引入的全新编程风格，喜欢的大有人在，不喜欢的也同样大有人在。Kresten 喜欢 Erlang 的语法/不喜欢 Java 的语法，同时又喜欢 Java 的虚拟机，两者的奇妙组合就产生了 Erjang 。而 xushiwei 喜欢 C/C++ 的语法/不喜欢 Erlang 的语法，同时也喜欢用顺了手的 C/C++ 环境，这两者于是就组合出了奇妙的 CERL 。我比较土，也不求甚解，对语言缺乏强烈的认同感，目前看来在 linux 下似乎没有比 Erlang/BEAM 更称手的了，那就继续用好了。
我觉得说 如果单单把erlang语言移植到其他系统是比较容易的事情. 但是ERTS不仅仅是语言的VM(这部分占不到20%), 更主要的是运行期为erlang的网络和并发特性提供的大量支持(这部分是几乎不可能去移植的).
所以我绝对不看好这个东西. 官方的版本每次都是小小的变动, 为的是维护Erlang已经建立起来稳定的名誉.
完全同意yufeng的观点。还有就是Erlang的最为本质的特点“软件容错”，也是无法
简单被模仿出来的。很多语言所谓的模仿，其实都只是“语法”层面的并发特性。
Erlang在“软件容错”方法的真正工程化特征，是很难被超越的。
按照 Keresten 的描述，他的 Erjang 应该是与 Erlang 在 bytecode 层面兼容的。也就是说，直接拿 Erlang 某个发行版 RunTime 的一整套 .BEAM 文件，就能直接通过 Erjang 在 JVM 上跑起来。而我们也知道 Erlang 只有为数不多的部分是 NativeCode 写出来的(VM/Driver/…，移植的主要工作量就是这些)，剩下的绝大部分都是 .BEAM 格式的 bytecode 。从这个角度来说，如果以这种方式来做移植“运行期为erlang的网络和并发特性提供的大量支持”(这些绝大部分都应该是以 bytecode 形式存在的代码)应该都会被“透明地”移植过去。
这当然不会是一件容易的事，其实我很怀疑这是否具有工程上的可行性。然而，仅仅从理论上讲，如果能从某个合理的角度切入，抛开实际的考量，我们确实也没法排除弄出一个实现出来的可能性(还记得去年就曾经看到日本人做的一个神奇项目，是用 JavaScript 做了一个和 Java Class 具有 bytecode 兼容性的东东，能在浏览器里直接跑 .class 文件)。技术的可能性是无穷的，尤其是对于一个完全开源的软件而言，更是如此。
其实，我对于 Erjang 也是谨慎的态度。
就算弄出来的东西，确实能跑，但会引入一些“不同的语义”，甚至产生出一套“方言”来，那将会是一件相当糟糕的事。
>>就算弄出来的东西，确实能跑，但会引入一些“不同的语义”，甚至产生出一套“方言”来，
>>那将会是一件相当糟糕的事。
这几乎是必然的。
看了下erjang的源代码,作者的决心还是很大的, 代码的时候也很干净. 不像之前的riak什么的根本就是豆腐渣工程…
@jackyz
有一点 jackz 误会我了，我很喜欢 Erlang 的文法。让我决定不用 Erlang 来进行开发的原因，最主要一点是我认为大型工程应该用静态类型语言来做。所以 cerl 是我的一个开始，如果可以实践成功，我希望将 cerl 包装成为一个语言，语法上会接近于 Erlang，但是将会是静态语言。这种想法可能类似于 Scala。因为 Scala 其实是 Erlang + JVM + 静态类型。我个人并不喜欢 Java，从而讨厌一切与 Java 有关的东西，这一点是个性使然。
>>最主要一点是我认为大型工程应该用静态类型语言来做
C++是静态类型语言吧，AXD301的前身AXE-N用C++做了7年，失败了。
后来AXD301改用Erlang，3年就出了第一个版本。
静态类型还是者动态类型不是重点，重点是语言针对其所针对领域的“工程化”的程度，这也是目前其他所有模仿Erlang的语言所缺少的。这些语言只是在仿照“形”上的相似，缺乏对所针对的领域的“工程化”分析，也就是Joe Armstrong博士论文第二章所描述的东西。
@yufeng
You are absolutely right that it will be impossible to establish exact same semantics; but perhaps in the process we will learn what is really the semantics of Erlang. Because it is much more than meets the eye. For example: An important part of Erlang is the concurrency semantics, and the the behavior of the scheduler in relation to mailboxes, etc. This is an area where much of the experience of erlang users is encoded.
Time will show if this project is useful for anything other than teaching me Erlang.
For now, I can run the Eshell, and compile/load simple files: http://bit.ly/ajHx3G