undefined | Better HN

0 pointspron10y ago0 comments

> The ease of scaling across machines

What does that have to do with the VM implementation?

> fault tolerance

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

> low latency variation

Nothing that can't be achieved on the JVM. Much of the low-latency Erlang enjoys is because relatively little data is kept on the Erlang heap anyway, and whatever significant amount of data is kept on the Erlang heap, it's in non-GCed ETS. If that's your way of achieving low latency variation, Erlang can do better on HotSpot.

> Besides that, god prevent erlang to become just-another-JVM-language, I embrace competition.

If your goal is not to have the best language environment you can but to show the world you have impressive results for the effort you've put in, then that's a whole other discussion.

And if all you want is competition, you can have Erlang on BEAM and the JVM. Why tie the language to one VM? Many JVM languages also compile to JavaScript, too (Clojure, Kotlin, Scala, Fantom and probably more)

0 comments

vezzy-fnord10y ago

Technically the distribution protocol is a property of the runtime system, but it does cooperate with the VM for details like term serialization.

True, that is a selling point, except that 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).

This is only the case for NIFs and (linked-in) port drivers, i.e. the facilities that are dynamically linked into the runtime. Regular ports which rely on a byte-oriented interface and are controlled by an Erlang process are safe, as are external nodes (typically, but not necessarily C nodes) which use the erl_interface libraries for marshalling/unmarshalling into and from Erlang terms, and thus can be treated from the programmer's perspective like they're regular Erlang VM nodes.

NhanH10y ago

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

pronOP10y ago

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

nickpsecurity10y ago

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.

1 more reply

sjtgraham10y ago

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.

seiji10y ago

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.

j / k navigate · click thread line to collapse