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

C++是静态类型语言吧，AXD301的前身AXE-N用C++做了7年，失败了。
后来AXD301改用Erlang，3年就出了第一个版本。

静态类型还是者动态类型不是重点，重点是语言针对其所针对领域的“工程化”的程度，这也是目前其他所有模仿Erlang的语言所缺少的。这些语言只是在仿照“形”上的相似，缺乏对所针对的领域的“工程化”分析，也就是Joe Armstrong博士论文第二章所描述的东西。

这几乎是必然的。

yufeng :
我觉得说 如果单单把erlang语言移植到其他系统是比较容易的事情. 但是ERTS不仅仅是语言的VM(这部分占不到20%), 更主要的是运行期为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 也是谨慎的态度。

Erlang 在 JVM 的实现，想必会也受到 JVM 体系固有的限制，如果因而破坏语言本事的一些核心特性，比如，进程的独立性，GC的独立性之类的，那么在具体选择时，就值得我们这些使用者再三斟酌了。

就算弄出来的东西，确实能跑，但会引入一些“不同的语义”，甚至产生出一套“方言”来，那将会是一件相当糟糕的事。

所以我绝对不看好这个东西. 官方的版本每次都是小小的变动, 为的是维护Erlang已经建立起来稳定的名誉.

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 更称手的了，那就继续用好了。