This is true in general, but not entirely accurate. When a Java thread crashes it doesn't bring down the whole JVM any more than when an Erlang process does. Just the one thread dies. With Quasar you get the same isolation for fibers.
It is true, however, that one thread in Java could negatively impact the performance of another by triggering a GC, while in Erlang each process has its own private heap. The Erlang approach (or the BEAM approach, rather, as its a feature of the VM - not the language) provides this isolation because Erlang was designed for systems where fault-tolerance is the number one concern. But it has its cost, too. The lack of a global heap makes it impossible to implement useful shared data structures, so Erlang provides some simple shared data-structures (like ETS) implemented in C, but those aren't garbage collected.
Also, the JVM has a big performance advantage over BEAM. That's why quite a few Erlang projects need to code some performance critical functions in C. But once you do that, you lose Erlang's isolation guarantees: a failed C function could bring down the entire application, and one that's stuck in an infinite loop will affect the performance of other processes.
> I am also not quite sure about any superior concurrency constructs which aren't based on OS primitives, but I am not Java guy.
You can start by looking here: http://docs.oracle.com/javase/7/docs/api/java/util/concurren...
None of these classes uses kernel mutexes or other synchronization mechanisms.
I think this is inaccurate also.) Technically there is no memory protection from one pthread to another, so "crashed" pthread could damage shared data or the common stack. It is, however, not JVM's problem but of the pthreads as a concept, and Armstrong argued that only share-nothing architecture (process-based) could be fault-tolerant, and pthreads are just "broken by design".
If fault-tolerance is your most important requirement, that far exceeds in its importance any other requirement, then by all means use BEAM. It was designed for precisely that kind of application.
If, however, fault-tolerance is just one of several important requirements, then the JVM will be the better choice in many circumstances.
I have been working with the JVM for many years, on large and complex systems, and i recall exactly two actual crashes - one due to a HotSpot compiler bug, and one due to a stack overflow bug in the garbage collector.
I have been part of various Java communities in physical and virtual space for as many years; we spend a lot of our time talking (or shouting) about problems we face with Java and the JVM, and although there is no shortage of them, crashes are not something i hear other people complaining about either.
Another well-known story is when digg.com was switched to Cassandra. It keep crashing under load.
To be clear, when one gives it two times the size of workload of RAM, running only one JVM process on a whole server and has no fluctuation either in data flows or connection rate (they call it tuning), well it works.
In my opinion, however, as I could gather from the writings of mr. Armstrong, (one of) the fundamental problem with JVM is that it lacks a process isolation, and when it crashes, everything crashes completely. He explicitly pointed out this in his thesis - JVM cannot provide fault-tolerance due to being a mere user-level multi-thread process.
As a person who had experience of running huge Java crapware like Business Objects I could tell that yes, it crashes and it crashes often, and when it crashes there are situations in which there is no way to preserve data integrity and plain re-installation is required.
I am also not quite sure about any superior concurrency constructs which aren't based on OS primitives, but I am not Java guy.
Go is a way of doing things without a VM.)