You’re moving the goal post. The JVM does provide real time observability into your application.
Personally I think in a terminal with just text is inferior to a proper gui tool. If you really want this jcmd can convert jfr data into different formats that you then can script against.
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).
You can write a library/tool that does exactly that, and the JVM offers an API precisely for that purpose. The reason such a tool isn't offered out of the box is that it trades off performance. For example, the JIT can optimise a variable or even an entire object away. When you want to inspect them at runtime, this would trigger a "deoptimization", where the representation would go back to the original bytecode from the optimised machine code. Observability that doesn't trigger deoptimization is, therefore, encouraged, but everything is available.
