BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.
The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!)
It has world-class introspection built in that gives you the power to observe and manipulate your running application through a REPL.
The BEAM has hundreds of features like this, because the BEAM is more of an OS than and VM.
I get it, you're a JVM expert, but the BEAM is more than a check list of optimizations that on paper the JVM can do.
I strongly suggest, before the next time you comment on an BEAM VM vs.JVM debate, please consider watching https://www.youtube.com/watch?v=JvBT4XBdoUE, "The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019"
and reading https://github.com/happi/theBeamBook " an attempt to document the internals of the Erlang runtime system and the Erlang virtual machine known as the BEAM."
Best of luck!
As an Erlang fan for many, many years, I am quite familiar with BEAM's design (and why I think Erlang would gain a lot by running on the JVM (or, more precisely, from implementing BEAM and OTP on top of the JVM). Aside from implementation details -- the JDK has simply had a lot more work put into it -- the main difference between the two is that BEAM is higher level, and the runtime itself does more things out of the box, while the JVM is lower level and you can do more in libraries (with no loss of performance, because Java is compiled to very efficient machine code).
Not only would Erlang and Elixir gain better performance and be able to reduce application's reliance on NIFs, but maintaining and evolving them would require less effort.
There is now (as of JDK 19, released six months ago) no capability offered by BEAM -- including runtime manipulation of code through a REPL -- that couldn't be implemented at least as efficiently as a library on top of the JDK. You can see the API here: https://docs.oracle.com/en/java/javase/20/docs/specs/jvmti.h...
The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.
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.
