JVM/CLR 上的 Erlang
我刚刚开始阅读 Joe Armstrong 的关于 Erlang 的书，并听了他在 Software Engineering Radio 上的精彩演讲。
它是一种有趣的语言/系统，随着多核机器的出现，它的时代似乎已经到来。
我的问题是：如何阻止它被移植到 JVM 或 CLR？ 我意识到两个虚拟机都没有设置为运行 Erlang 所需的轻量级进程 - 但这些不能通过线程模拟吗？ 我们能否在非 Erlang 虚拟机上看到轻量级或精简版的 Erlang？
I've just started reading Joe Armstrongs book on Erlang and listened to his excellent talk on Software Engineering Radio.
Its an interesting language/system and one whose time seems to have come around with the advent of multi-core machines.
My question is: what is there to stop it being ported to the JVM or CLR? I realise that both virtual machines aren't setup to run the lightweight processes that Erlang calls for - but couldn't these be simulated by threads? Could we see a lightweight or cutdown version of Erlang on a non Erlang VM?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您无法使用 JVM/CLR 库，因为它们依赖于可变对象。
Erlang 异常处理与 JVM 和 CLR 异常有很大不同，您需要以某种方式处理它。
将进程实现为线程意味着任何相当大的 Erlang 系统都会很快耗尽内存（创建时我的机器上的进程大小：1268 字节，CLR 中的线程堆栈大小：1 MB），并且进程之间的通信比 Erlang 慢得多。
您可能想要的是 JVM 或 CLR 上的 Actor 模型实现。
Scala 和 Clojure 已经提到过。 另外，JVM还有很多Actor的实现：
Kilim，函数式 Java、Jetlang、演员协会，ActorFoundry a>，以及至少一个用于 CLR 的：Retlang，它可以在任何 JVM/ 中使用CLR 语言。
You could not use JVM/CLR libraries, given their reliance on mutable objects.
Erlang exception handling is quite different from JVM and CLR exceptions, you would need to handle this somehow.
Implementing processes as threads would mean that any sizable Erlang system runs out of memory pretty fast (process size on my machine on creation: 1268 bytes, thread stack size in CLR: 1 MB) and communication between processes is much slower than in Erlang.
What you probably want is an Actor Model implementation on JVM or CLR.
Scala and Clojure have already been mentioned. In addition, there are many Actor implementations for JVM:
Kilim, Functional Java, Jetlang, Actors Guild, ActorFoundry, and at least one for CLR: Retlang, which can be used from any JVM/CLR language.
出于教育原因，我们正在为 CLR 实现 ErlangVM 的一个子集。 我们受到 Kresten Krab Thorup 和他的项目 Erjang（一个基于 JVM 的 Erlang VM）的启发。 Erjang 使用 kilim 框架来表示轻量级进程，并开始引起人们的关注。
Javalimit - Erjang 的作者博客。
Erjang 存储库
For educational reasons, we are implementing a subset of ErlangVM for CLR. We were highly inspired by Kresten Krab Thorup and his project Erjang, a JVM based Erlang VM. Erjang uses kilim framework for representing lightweight processes, and it starts to attract attention.
Javalimit - Erjang's author blog.
Erjang repository
这是一个很好的讨论。 一些上下文可能有用。
去年 11 月的 Erlang 邮件列表：
漫长讨论的开始线程
继续此处
有点精神这里
并以 Joe 的 贡献。
我对关于 JVM 上的 Erlang 的争论有何贡献？ 不，这不是一个好主意:(
This is a well trod-discussion. Some context might be useful.
From the Erlang mailing list last November:
The start of a long discussion thread
continuing here
and going a bit mental here
and ending on Joe's contribution.
My contribution to the debate about Erlang on the JVM? No, not a good idea :(
事实上，什么也没有。 您可能会看一下 Clojure，这是一种构建在 JVM 上的有趣的函数式语言。
Nothing at all, actually. You might have a look at Clojure, which is an interesting functional language built on the JVM.
Axum——CLR 上的一个孵化项目——显然受到了启发由埃尔兰.
Axum -- an incubation project on the CLR -- was clearly inspired by Erlang.
Erjang 是 Erlang 的虚拟机，在 Java™ 上运行。
Erjang is a virtual machine for Erlang, which runs on Java™.
我不知道这有什么技术问题。
实际上，Scala（一种 JVM 函数式语言）使用所谓的 Actor 模型，它与共享的 Erlang 模型非常相似，并且据我了解，它大量借用了 Erlang 模型。没有并发。
线程无法模拟 Erlang 进程。 它们太重了。
I don't know of any technical problem inhiting this.
Actually Scala (a JVM functional language) uses what is called an Actor Model that is very similar to, and as I understand it borrows heavily from, the Erlang model of shared-nothing concurrency.
Threads could not simulate Erlang processes. They're much too heavy-weight.
只是为了完整起见，有关主题的附加来源。
Just for completeness additional source about topic.
可能的？ 是的。 实际的？ 嗯，可能不会； 他们以非常不同的方式解决不同的问题，因此他们做事的方式有很多重大差异。 这将使移植变得困难，并且性能可能会受到严重影响。 这并不意味着它无法完成，只是有更好的方法来实现此类移植所带来的功能。
Possible? Yes. Practical? Well, probably not; they solve different problems in very different ways, and thus have lots of major differences in the way they do things. This would make porting hard, and performance would likely suffer severely. That doesn't mean it can't be done, just that there are better ways to accomplish what such a port would bring to the table.