It's the actor model all the way down... that's the abstraction.
Simple systems, are easy to manage, complex systems are harder to manage, hence why you need a full blown GUIS to manage the JVM, because it does everything, and tries to satisfy every use case, so it has to handle every use case.
The author of the article you linked is about a decade out of date. "The state of the art in observing your JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations." -- that has been untrue for quite some years now. The basic observability offered by the JDK is now the Flight Recorder, a low-overhead in-production tracing and profiling engine that BEAM is many years away from being able to achieve.
The JVM supports all the same runtime observation and manipulation as BEAM. If you want to use them via a shell -- you may. If you want to use the actor model "all the way down" you can do it. The JVM is simply a virtual machine at a lower level than BEAM, but it does provide all the primitives the Erlang model needs.
The reason I'm telling you this is that I think that targeting the JVM would allow Erlang/Elixir to evolve faster -- enjoying the low-level work done by the large OpenJDK team -- as well as reach a wider audience. At the same time, the wider Java platform community will be exposed to all the great ideas that have come out of Erlang. All the necessary foundational work is now, finally (as of JDK 19), in place.
It is a goal post move. You went from "Beam provides real time observability" to "real time observability is only in a terminal with a repl" when provided with facts that the JVM also provides real time observability.
> a "Proper GUI tool" is not.
I don't know what this means.
> hence why you need a full blown GUIS to manage the JVM,
Did you read the post you linked? The author required a GUI written by someone else.
I don't know what point you're trying to make anymore, you're just spitting out random sentences, that don't have to do with anything I was replying to (real time obserability).
a "Proper GUI tool" is not.
the BEAM is an OS, the JVM is not.
and as of matter of fact.
https://mrjoelkemp.medium.com/jvm-struggles-and-the-beam-4d9...
It's the actor model all the way down... that's the abstraction.
Simple systems, are easy to manage, complex systems are harder to manage, hence why you need a full blown GUIS to manage the JVM, because it does everything, and tries to satisfy every use case, so it has to handle every use case.
https://www.youtube.com/watch?v=SxdOUGdseq4