I don't know what that means. The JVM itself is at least as reliable as BEAM, and probably more so -- it's subject to both more development testing and field testing -- but what needs high reliability is applications. The JVM runs much more critical code than BEAM does, and on a far wider scale and more stressful workloads. The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming model that matters. The JVM can now support the Erlang model at least as well -- and, I claim, significantly better -- than BEAM ever could with its limited resources. BEAM's Achilles heel has always been performance. That has harmed Erlang application's reliability, as they need to depend on unsafe native code -- that can crash the entire process -- much more than JVM applications.
> The VM itself is the cause of neither Java's reliability nor Erlang's. It's the programming model that matters. The JVM can now support the Erlang model
That's a common misconception. There is a huge practical difference between "being able to write share-nothing" and "having whole ecosystem built around it". While you're referring to Erlang running unsafe native code, you're completely ignoring the Java running unsafe Java code. To ensure guarantees like "share nothing" or "restartable processes" Erlang developer just needs to write only Erlang and Java developer needs to carefully pick every dependency and almost always rewrite some of them.
That's the exact reason why Akka didn't replace OTP: you're most likely using the dependency which is not written with Akka, and it might share mutable memory, use global mutable state etc. So, even with possibility of writing Erlang-like software, you most certainly will end up with Frankenstein where some parts are fault tolerant, immutable, functional and reasonable, and some parts are oldschool java 8 bullshit.
Do you know what is the definition of DSL? It is when you write your code in one language and get exception in another. And that's exactly why almost every JVM language (except Java) is a DSL.
You just can't have guarantees Erlang has without rewriting everything with your Akka of the day.
I think you misunderstood my point. I wasn't trying to argue for Java over Erlang. The people writing Java will continue writing Java, and people writing Erlang will continue doing that.
I was merely pointing out that at this point, the JVM offers a great platform for Erlang itself, which could both increase its visibility and give it a technological boost. You could have everything be Erlang, top to bottom, with far better performance than BEAM could ever achieve, less work, and better interop with where a lot of people actually are.
There could be some disadvantages but overall I think it would be a great opportunity, and one that Erlang could really use.
> And that's exactly why almost every JVM language (except Java) is a DSL.
Other JVM languages choose to have "exceptions in Java" because it's so much less work for them to use existing libraries and they consider it a small enough price to pay. But even if you want virtually all of it to be Erlang, it would still be less work than BEAM.
You could even control exceptions and stack traces, as that's programmable:
