I am really appreciate your drive and effort, thank you for the reply.
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.
> 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.
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.
> 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.
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".
True, but this is not black-and-white, but a matter of degree. Erlang processes also share memory: ETS. A crashed process could well leave an ETS table in an applicatively illegal state. So isolation is a scale. With Quasar we try to tip the scale closer to Erlang's isolation levels, but, as I've said, shared data structures could be extremely useful, too.
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.
Your experience of the JVM crashing and crashing often is, i believe, rather unusual.
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.
I do remember Google Wave developers also mentioned crashes on this very site. Actually, according to them, it was one of the problem with Wave project. I cannot provide an exact citation but it is quite easy to crosscheck.
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.)