
Erjang is a virtual machine for Erlang, which runs on Java - fogus
http://wiki.github.com/krestenkrab/erjang
======
vladev
Call me a skeptic, but this project ditches Erlang's awesome VM and takes only
the clunky language syntax and puts it on the JVM.

I wonder how things like process isolation will work out.

~~~
sriramk
You beat me to it. My first reaction was "Wait - how is preserving Erlang's
syntax but losing the VM a good thing?". I'd love projects going the other
direction - a more modern syntax built on Erlang's rock-solid VM + OTP
libraries.

~~~
oconnor0
What are the names of some of those projects?

~~~
frig8
Reia <http://wiki.reia-lang.org/wiki/Reia_Programming_Language>

Lisp Flavored Erlang <http://github.com/rvirding/lfe>

------
jganetsk
_In Erjang, every node runs on a single heap, and so global gc will sometimes
happen. On the other hand, Erjang does not copy messages between processes —
they are simply shared, and so that might leave some room for savings._

Will be interesting to see what happens, no doubt. Message copying will have
to be implemented, anyway, for inter-node communication.

 _I don’t know how Java’s various garbage collector compares to the one in
Erlang, but I guess that Java’s is significantly faster._

Doubtful. A garbage collector specially designed for small heaps, running on
such, will outperform Java's general-purpose ones. Also, Erlang's GC is stop-
the-world (where "world" here is an Erlang process), and that yields numerous
benefits. I think Java's GC will not be better for erjang.

~~~
silentbicycle
Right, and due to Erlang's lightweight processes, it's not unusual to have a
process finish before it needs to do any garbage collection. You can tune for
this by spawning a process with a larger heap than the default - if you know
that it tends to grow up to a certain size and then finish, you can just spawn
it with that much to start and it will skip GC entirely.

------
iamaleksey
This doesn't make much practical sense. However, implementing Erlang on top of
the JVM seems like an awesome way to learn Erlang and JVM internals at the
same time.

------
knv
Previous discussion on this matter:
<http://news.ycombinator.com/item?id=544755>

------
j2d2
I'm curious as to what effect Java's crappy tail recursion has I tried running
a ruby sudoku solver in jruby that functions basically like an n-queens solver
and it couldn't handle it. Not sure I'd expect erjang to do better since the
issue is with the jvm.

~~~
bad_user
Tail-recursion can be implemented on top of the JVM.

For self-recursion you just issue a GOTO. For mutual recursion, the compiler
can generate a trampoline.

There are two problems with a trampoline ... one is that the stack-trace will
no longer be accurate. And the second problem is that interoperability with
Java suffers because the bytecode of the method or that of the call-site will
be different from what-you-see in your code.

For example one way of doing it is to modify the recursive function ... fn (a)
=> b ... to be ... fn (a) => M[b] ... where M[b] contains either the returned
value "b" or the reference + arguments of the next call done by the
trampoline. And then the compiler modifies the call-sites to call the
trampoline instead of our method.

About efficiency ... if you want to have a generic trampoline module (instead
of many trampolines defined for each group ... which would consume permgen
memory), you could implement such a trampoline on top of the new invokedynamic
support in JDK7 ... this could allow for the call-sites in the trampoline to
be cached and ultimately JITed. I'm not sure if invokedynamic could help here
(I know little about how the call-sites will be cached) but I don't see why
not.

~~~
gordonguthrie
> the stack-trace will no longer be accurate

...as indeed it isn't in Erlang...

