[pron]

All the more reason to use Erlang/JVM alongside other JVM languages. Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get.

And Erlang/JVM can be even better than Erlang/BEAM at everything Erlang/BEAM is good at. There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case). BEAM's Erlang specialty simply means its development required relatively little effort to run Erlang reasonably well. It doesn't mean the JVM can't run Erlang better, and at this point in time we have every reason to believe it can run Erlang much better than BEAM.

[nickpsecurity]

"Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get."

It's not the best you can get but polyglot support is a strength.

"There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case)."

Still got it beat on latency and security risk per dollar spent: zero for Erlang w/ 5 digits for RT-JVM. If these aren't an issue, then Erlang on JVM may indeed be a superior option. I can imagine many use cases where it would be.

[pron]

> zero for Erlang w/ 5 digits for RT-JVM

RT-JVM's guarantee scheduling latencies of 2us. Erlang doesn't come close. In practice, stock HotSpot has better latency than Erlang. Erlang's "guarantees" are only in effect when 1) no native code is used, 2) no global effects are used (some process registrations, binary heap, etc.).