> Those are impossible to achieve without a purposely built VM. No solution on Sun JVM will ever be able to replace Erlang for applications which require low-latency processing.
Impossibility claims are very hard to prove and are often wrong, as in this case.
First, commercial hard real-time versions of the JVM with strong timing and preempting guarantees exist and are commonly used in the defense industry. To the best of my knowledge, there are no mission- and safety- critical weapon systems written in Erlang; I personally know several in Java. These are systems with hard real-time requirements that blow stuff up.
In addition, Azul's JVM guarantees no GC pauses larger than a few milliseconds (though it has no preemption guarantees).
But the fact of the matter is that even a vanilla HotSpot VM is so versatile and performant, that in practice, and if you're careful about what you're doing, you'll achieve pretty much everything Erlang gives you and lots more.
People making this claim (Joe Armstrong first among them) often fail to mention that those features that are hardest to replicate on the JVM are usually the less important ones (like perfect isolation of processes for near-perfect fault-tolerance requirements). But when it comes to low-latency stuff, the JVM can and does handily beat Erlang.
P.S.
As one of the authors of said ring-benchmark-winning actor frameworks for the JVM, I can say that we do hot code swapping already, and if you buy the right JVM you also get a fully concurrent GC, and general performance that far exceeds Erlang's.
> First, commercial hard real-time versions of the JVM with strong timing and preempting guarantees exist and are commonly used in the defense industry. To the best of my knowledge, there are no mission- and safety- critical weapon systems written in Erlang; I personally know several in Java. These are systems with hard real-time requirements that blow stuff up.
That's why I said Sun JVM in first place. Azul and realtime Java are those purposely built VMs I mentioned.
Your claim about Sun JVM is more interesting. If it is so versatile why there are no network applications on JVM exist that provide at least adequate performance? Sure, JVM is blazing fast as far as code execution speed goes; the point is that writing robust zero copy networking code is so hard on JVM that this raw execution speed does not help.
I'm not sure what you mean when you say network applications that provide at least adequate performance. Aren't Java web-servers at the very top of every performance test? Isn't Java the #1 choice for low-latency high-frequency-trading applications? Aren't HBase, Hadoop and Storm running on the JVM?
The whole point of java.nio introduced over 10 years ago, back in Java 1.4, is robust zero-copy networking (with direct byte-buffers). Higher-level networking frameworks, like the very popular Netty, are based on NIO (although, truth be told, up until the last version of Netty, there was quite a bit of copying going on in there), and Netty is at the very top of high-performance networking frameworks in any language or environment.
Impossibility claims are very hard to prove and are often wrong, as in this case.
First, commercial hard real-time versions of the JVM with strong timing and preempting guarantees exist and are commonly used in the defense industry. To the best of my knowledge, there are no mission- and safety- critical weapon systems written in Erlang; I personally know several in Java. These are systems with hard real-time requirements that blow stuff up.
In addition, Azul's JVM guarantees no GC pauses larger than a few milliseconds (though it has no preemption guarantees).
But the fact of the matter is that even a vanilla HotSpot VM is so versatile and performant, that in practice, and if you're careful about what you're doing, you'll achieve pretty much everything Erlang gives you and lots more.
People making this claim (Joe Armstrong first among them) often fail to mention that those features that are hardest to replicate on the JVM are usually the less important ones (like perfect isolation of processes for near-perfect fault-tolerance requirements). But when it comes to low-latency stuff, the JVM can and does handily beat Erlang.
P.S. As one of the authors of said ring-benchmark-winning actor frameworks for the JVM, I can say that we do hot code swapping already, and if you buy the right JVM you also get a fully concurrent GC, and general performance that far exceeds Erlang's.