Hacker News Reader

Comment by rdtsc | Hacker News Reader

The main power of Erlang comes from the ability to build fault tolerant and highly available systems. Fault tolerance was the main motivator behind Erlang's existence, not any of the thing you mention. Two of those things (actor model and hot code replace) fall out of that one requirement. Fault tolerance needs process isolation, that leads to actor model. Minimization of shared state leads to a immutable data structures + a functional approach. High availability and tolerance for upgrade downtime leads to hot code replace.

And fault tolerance is exactly what JVM doesn't have. It shares a common garbage collector and there are other things.

That is the main problem with those who claim "oh here is a faster Erlang library in language X", yes, one can copy some of the features into language X but unless full process isolation is copied, it is not really an Erlang replacement library/lanuage.

View on HN

You can add the soft realtime characteristics of the VM to the mix. That's not something you can just add to the JVM as a library either.

You're either realtime or you're not. If you have hard and fast time requirements to perform certain actions then you're real time. (e.g. 3 ms. to decide whether or not to turn the cruise missile or it hits a hospital). There is no 'soft' realtime.

There is soft realtime. You don't have to have hard and fast time requirements, or nothing, you can have more relaxed statistically defined requirements. That is soft realtime.

Systems are not divided into cruise missile control systems and everything else. There is a continuum in between. A phone system where the calls need to routed in the 100 milliseconds or less 99.999% of the time is acceptable for example, while one where no such guarantees can be provided at all is not acceptable. It is not a realtime systems but it is pretty close, so it would be called soft realtime.

Erlang does not have a common runtime for its processes? What happens to the isolated Erlang processes when the VM fails to allocate more memory from the OS? Does the whole VM crash, or just the process that caused the memory allocation attempt?

That is one of the few cases that will take down the whole VM (at least, as of a few versions ago). Due to Erlang's concept of process isolation, there's not really a sensible course of action for the VM to take if it runs out of memory. Maybe just killing the individual process or running a GC pass on every process and trying again might be a better approach than hosing the whole runtime, maybe they've fixed it. Either way, the frequency with which this happens in production Erlang apps seems to be low enough that it's essentially a non-issue for most of the Erlang community.

> What happens to the isolated Erlang processes when the VM fails to allocate more memory from the OS?

It suspends your process, then logs into newegg.com and buys more memory sticks for your sever. You know it is just a regular VM and doesn't have magic in it. If you use up all the memory on your server you are screwed probably.

You could set up a monitor to see which erlang process is eating memory and what rate and then decide what to do, kill the process, restart the whole node, or report someplace.

EDIT: see http://www.erlang.org/doc/man/memsup.html

Reply on news.ycombinator.com