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.
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
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.
>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.
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.
