Erlang Doesn’t Fit The JVM

<i>At it’s heart the JVM is designed to run OO languages very efficiently. This is why languages like Ruby and Python are (mostly) easily ported to the platform...<p>However, the JVM is less suited to running non-OO languages. Languages like Erlang, Haskell, and Scheme provide features, like tail recursion, closures, and continuations, which are not prominent in the mainstream OO world the JVM targets. They depart far enough from the OO model to make the JVM a poor platform choice.</i><p>That's strange, because all of the Smalltalk VMs are capable of closures and many of them can do continuations, yet Smalltalk is often cited as one of the purest OO environments. (I'm also fairly sure that tail recursion can be done as a compiler trick.)<p>That said, there are real limitations of the JVM. Most Smalltalk VMs can be targeted by a Java compiler to do a dandy job as a JVM. It's much harder to target Smalltalk for a JVM, unless you limit the capabilities of the environment. (Particularly runtime compilation.)

first class closures are not a JVM problem, but a language problem. Moreover, closures (lexical closures) exists in java itself: an annonymous inner class captures (well, on demand, for perf reasons) all the lexical terms visible at the point of use.<p>the tail call is a bytecode security problem. Looks like this problem has been solved and will be merged.

Isn't LLVM a more interesting universal machine to target anyway?

Erlang's VM is unmatched scaling above 16+ cores (for example process migration <a href="http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-design.html" rel="nofollow">http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-desig...</a> ) this is something that the java vm hasn't even begun to look at.

I feel your pain with java serialization.<p>The fact that you cant serialize exceptions to notify systems connected to a JVM that something blew up is just insane.<p>All objects should be able to be serialized (in binary) from one system to another as long as JVM versions and class libraries match... end of story.

SISC targets the JVM with tail call optimization with some trickery. <a href="http://sisc-scheme.org/" rel="nofollow">http://sisc-scheme.org/</a>

Why would you even bother doing this in the first place. Erlang's VM is one the things that makes it interesting, Not the syntax.<p>The only reason I can see is the OTP libraries, but then again, why not just use the Erlang VM as you get so much great stuff for Actor based concurrency out of it.

Ruby language on the Erlang VM -<p><a href="http://on-ruby.blogspot.com/2009/03/reia-new-dynamic-language-on-erlang-vm.html" rel="nofollow">http://on-ruby.blogspot.com/2009/03/reia-new-dynamic-languag...</a>

If you want a VM that's totally geared towards "dynamic languages" you should definitely check out Parrot ( <a href="http://www.parrot.org/" rel="nofollow">http://www.parrot.org/</a> ).

He doesn't mention the Erlang scheduler and processes. Shouldn't be that hard to hack into the JVM, but as I've commented elsewhere, that's only half the battle...

If these are real limitations of the JVM, what does that say about Clojure?