Erlang on the JVM | Hacker News Reader

Erlang on the JVM

wiki.github.com

57 pointssilkodyssey16 comments

I mostly use Clojure these days, but I'm really happy that other languages have implementations on top of the JVM. The JVM is a mature beast with hundreds of man-years of effort put into its development. The more languages use it, the better.

This may not be the best place to ask about it, but I figure it's worth a shot. Anyone happen to have any documentation on the BEAM binary format ( I found http://www.erlang.se/~bjorn/beam_file_format.html but it's quite old) and the opcodes used in it?

see this post from a while ago too - "Erlang Doesn’t Fit The JVM": http://www.planeterlang.org/en/planet/article/Erlang_Doesnt_...

Most of those objections are adressed at the bottom of the github page.

I think the point is that certain core aspects of erlang are not a 1:1 port between the 2 VMs. BUT THAT DOES NOT MEAN that erlang cannot be implemented on the jvm, you just trade off one set of tricks for another. As long as the language is not compromised.

Notice how its written that in Erjang you just use shared variables to pass messages between two processes VS copying messages. There you go. If the VM handles thread safety for you, then what do you care that the variable is shared vs not shared or mutable vs not mutable (in the underlying vm)? Shared just means better performance. Wasent the whole point of erlang to let your VM handle sharing vs copying and isolating processes; while you code multi-processing, erlang uses whatever it wants for efficiency.

"If the VM handles thread safety for you, then what do you care that the variable is shared vs not shared or mutable vs not mutable (in the underlying vm)?"

Nobody should. Mutability or immutability is a property of programs, not languages. Some languages make it syntactically impossible to express mutation, but it's still all machine language in the end, which allows quite arbitrary mutation, so the only reason those languages can work is that they choose to refrain from mutation in their VM.

This looks really cool. It uses Kilim, the lightweight threading library for java, that I hadn't heard of before:

http://github.com/kilim/kilim

I have been looking for something similar for C but have not been able to find anything.

+1 on the Kilim comment, I hadn't seen this before either but it is well worth taking a look.

I met Kresten at the Erlang Factory this year - he's an incredibly talented developer and gave a great talk on the project. My sense as a relative Erlang 'outsider' is that the Erlang folks were skeptical at first but warmed to him as the conference went on because it was clear that he was addressing a lot of the concerns that running on the JVM was impossible (tail recursion, message passing, etc)...

"Good question. Well, I just wanted to learn Erlang, and so this felt like a good way to get through all the details. Seems to be working — I am learning erlang!"

That's how the Mono project started :-)

Yeah! I think porting nginx to JVM is the next big think? Anyone?

Even if it did, bloody why? Why why why would you do this. I'm sorry but I'm no fan of Erlang syntax.

Wouldn't it be much better to port another language to the Erlang VM (like Ruby) than the other way around?

I'm puzzled why you would question the motivation of porting erlang to run atop the JVM.

Just because you don't like erlang syntax and would prefer to have ruby on top of BEAM, doesn't mean that others should not undertake this port.

Rather than question erjang, why not start your ruby/BEAM port?

Edit: better grammar.

I'm sorry but I really dislike Erlangs syntax more than I like it's concurrency. I'm not saying Erlangs bad just that I hate how it looks.

Maybe others don't share your opinions.

Just a thought.

Probably not, they're not based on any form of logic.

Reply on news.ycombinator.com