Erjang - A JVM-based Erlang VM | Hacker News Reader

Erjang - A JVM-based Erlang VM

infoq.com

49 pointsKototama20 comments

When should we expect to see someone run Erjang on Google AppEngine?

How do you suggest to handle Distributed Er[l|j]ang on GAE Java?

GAE and AWS Beanstalk are great fit for web apps and web sites, where each worker is identical.

In case of Er[l|j]ang each node will need to have different node name and be connected to other nodes, otherwise it will not be much useful to me.

I also need to launch different clusters, so it getting complicated.

this reminds me of the effort to port erlang to android. both projects are of questionable utility, but so is climbing mount everest

http://www.burbas.se/artiklar/erlang-for-the-android-plattfo...

you can install CouchDB from the Android market

Flash warning, please.

my main question is why? Seems to be the worst of both worlds..... All the pain of Erlang syntax without any of the incredible stability and scalability of Erlang.

The erlang vm isnt magical, erlangs stability is derived from the semantics of the language and that should transfer to the jvm fine.

on the same vein erlangs syntax and semantics are heavily linked, erlangs syntax is not some afterthought with a vm that makes everything stable, its a core feature of the language and a big part of why its a pleasure to program and rock solid

Erlang VM and OTP is magical. Erlangs stability is derived from OTP, having process hierarchies, running multiple servers, and designing VM/language/OTP from the ground up and continuously there after as a integrated system capable of many nines uptime.

JVM is awesome in other ways.

OTP is a massive part of erlang applications stability and OTP is written entirely inside userland, it needs a VM which provides process isolation and message passing which isnt (obviously) beyond the JVM, sure it wasnt design from the ground up to do so but that does not mean it wont (and doesnt) work

> erlangs stability is derived from the semantics of the language and that should transfer to the jvm fine.

From what I understand Erlang depends heavily on green threads, which are no longer available on the JVM.

You can implement green threads yourself.

How would you do that in Java given that you can't reify the stack?

Erjang is using Kilim (http://www.malhar.net/sriram/kilim/) which does bytecode rewriting to support coroutines (kind of green threads) on top of JVM. With Java 8, we're rumored to get coroutines in the JVM.

besides it being functional and process orientated, theres lots about erlang syntax, that is just cumbersome, unwieldy and unnecessary, the interested reader is refferred to http://damienkatz.net/2008/03/what_sucks_abou.html. To claim that stability is a facet of the syntax , is questionable given as it would imply that languages like reia http://reia-lang.org/ are less stable, which i would very much doubt. Also in terms of stability ive yet to hear of a jvm based project with 99.999% uptime. You seem to suggest that this is because all of the java programs out there are not written to the same standard, this clearly cant be true. Finally, I wait anxiously for the day that a single jvm can handle as many concurrent processes as a single erlang execution environment. This is all my opinion, but what you say doesnt really make sense to me.

I try to tackle some of these points in An Open Letter to the Erlang Beginner (or Onlooker) (http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlo...).

As for the nine nines (99.9999999%) in the Ericsson AXD 301 ATM switches, Please note that this is not an indication that none of the components in an Erlang-based system failed, but that a general switch system was available 99.9999999% of the time, planned outages included. This is partially because Erlang is built on the notion that a failure in one of the components should not affect the whole system.

>Also in terms of stability ive yet to hear of a jvm based project with 99.999% uptime.

Azul systems has said that for many clients, they've achieved perfect reliability in terms of uptime, and that the only reason they don't have five nines uptime is because deployments happen often enough that it doesn't count as uninterrupted uptime.

> Finally, I wait anxiously for the day that a single jvm can handle as many concurrent processes as a single erlang execution environment.

It sounds like you are talking nonsense. Do you understand that a 'single jvm' is one process, so to say that a single jvm can handle as many concurrent processes is meaningless. Do you mean threads? I'm quite certain the JVM's thread scalability is much higher than erlang's vm. Are you familiar with the architecture of either?

yes I meant processes as in the generic term you might say executions as erlang process are different to Java threads. I meant a comparison of concurrent 'activities' as comparing a Java thread model to an erlang process model is somewhat pointless. I am interested in any Java program you might have that can run thousands of threads without grinding to a halt. please show me I didn't think it possible!

I'm doing simultaneousness processing of 700-800 transactions on my dual core laptop on the JVM. I think on a production grade server a thousand or so is not going to be an issue.

Your Garbage Collector and program's contention is going to a bigger scaling bottleneck than the JVM itself.

What's wrong with Erlang's syntax?

in an earlier talk, @drkrab said the project began as an exercise in learning erlang rather than to meet a production need

http://www.infoq.com/interviews/thorup-erjang

Reply on news.ycombinator.com