[weatherlight]

It's my understanding the state of the art in observing JVM-based applications is a combination of using thread dumps, gc logs, thread activity visualizations. Thread dumps give us a snapshot of the the name of the thread, its current running state (waiting, blocked, etc), and the stacktrace of the work its currently doing. GC logs give you a record of when and how much garbage was collected and Thread activity visualizations show you the timeline of thread moving between different running states.

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!

[pron]

You can do all that with the JDK, too, and at higher performance.

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...

[vips7L]

> The BEAM gives you the ability to see the bottlenecks in your system, via the REPL (in real time!)

The JVM has done this forever via VisualVM and more recently via Flight Recorder and Mission Control.

[weatherlight]

In a repl, in a terminal, with no reliance on the OS, with just text. so no the JVM doesn’t do this. It’s not the same.

[vips7L]

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.

[weatherlight]

There's no goal post moving, that's a virtue of the VM.

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

[pron]

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.

[vips7L]

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 have some extreme bias. Cheers mate.

[weatherlight]

Is the GUI apart of the VM? It is not.

[pron]

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.