[NhanH]

> True, that is a good selling point -- in theory. Indeed BEAM's process isolation is better than the JVM's on paper. In practice, so many Erlang systems have so much C in them (because Erlang isn't fast enough for the data plane), that they can still bring down the entire VM (not as if there aren't other ways of doing that even without native code), or they interfere with one another in other ways because of BEAM's poor support for shared concurrent data stuctures.

From my limited knowledge of Erlang, both of your points seem to be off the mark:

- Erlang systems have a lot of C code, but the purposes of BEAM was to manage those individual pieces and have those C component isolated such as they can crashed without causing system-wide issue.

- Actor model does not require programmer concurrent data structure to be effective. Actually that's the whole point of it...

[pron]

> Actor model does not require concurrent data structure to be effective. Actually that's the whole point of it...

That's complicated. Actors don't require concurrent data structures for the bits that don't require concurrent data structures but they do for the bits that do :) That's why Erlang has ETS. That's why you still need a database.

[nickpsecurity]

No it's not. The proper way to design systems is breaking them into pieces, implementing each one the best way for that piece, and connecting them together. So, if one can't do DB's with Actors, do it with another tool or model (eg Eiffel/Java w/ SCOOP). Use Erlang/BEAM for what it's good at. There's also tools such as ZeroMQ that make the integration fast & easier. You get the best of both worlds.

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

[sjtgraham]

When a NIF causes a crash it does take down the whole VM. I think the way to isolate NIFs is have them on their own nodes.

[seiji]

Kinda hilarious since we've had completely isolated ports for a loooong time. For non-data-intensive tasks, don't underestimate how fast speaking erl_interface over a unix pipe can be. Plus, free isolation, free fault tolerance and free supervision restarting without any networking required.

http://erlang.org/doc/reference_manual/ports.html (15.1)

Here's one of my old examples (no guarantees to its current effectiveness or correctness): https://github.com/mattsta/libgeoip-erlang/blob/master/c_src... — then the whole thing is opened and run from Erlang like https://github.com/mattsta/libgeoip-erlang/blob/70b58ef5ef8a...

It's just cleaner to stay outside direct VM linkage as much as possible.