I think it might actually be easier to inspect the BEAM over those other VMs. For one, it is much older and stable. And secondly, the BEAM has a lot of self-introspection features.

I highly recommend the talk The Soul of Erlang and Elixir by Sasa Juric which shows off the essence of the BEAM.

https://youtu.be/JvBT4XBdoUE

Since you brought up Sasa Juric, I will second that and also mention their book Elixir in Action. It really helped me get from toy examples to feeling confident running the BEAM in production. This is of course Elixir-centric, but the parts about OTP, inspecting running applications, etc. are really about the BEAM.

Yes, that book is excellent, and I definitely recommend it to anyone new to Elixir. I'd also recommend Joe Armstrong's Erlang book, even if one is eventually wanting to use Elixir.

Definitely way easier than tracing Node for any type of async exceptions.

I transferred from Node.js to elixir for that reason.

Uncaught throws, hanging errors - while someone much smarter than I could have done it better, I was doing a lot of async/retry of APIs with high failure rate and the BEAM just made it easy.

You can put node into debug mode after launch (SIGUSR1) and remote debug it as well, with sources, which is really incredible. This BEAM demo is rad, but chrome/v8 debug is actually really good too if you take the time to learn all the remote debug tips n tricks.

WHAT. I will catch up with you after the rabbit-hole.

I’ve got massive hopes for things like Bun, but especially Deno’s architecture of message passing, but I’m now humbled by my not knowing that existed in V8.

What is BEAM's version of Visual VM, JDK Flight Recoder or ETW?

To extend, the answer is the BEAM itself. It ships with these tools built in.

From the whole zoo of system probing stuff or the downright amazing dynamic tracing.

Have a quick look at https://www.erlang-in-anger.com/

Which is also available in JVM and CLR, with amazing graphical tooling, which was the main focus from my question, hence the examples.

In my experience... Nope it is not really. Not to that extend. But sure i get you.

Great question, check out Erlang’s “Observer”, it’s incredibly powerful, one of my favorite parts of the BEAM :)

Thanks.

> I’m not sure why I feel that way about BEAM.

unfamiliarity? Plus the problem of 'nobody ever got fired for running IBM' plaguing your work.

I'm not sure either why you feel that way. The BEAM has amazing tools to debug at runtime and explore/modify your system while it's running.

Yeah you'd need to learn it, but it's like any other tool.

Some comments about the prospect of using Phoenix with Gleam:

https://news.ycombinator.com/item?id=38037082

If you compare running a monolith on a singel server then you might be better off diagnosing problems in .Net. Though I think that is uncertain.

If you are writing a distributed system with plenty of microservices BEAM will be magnitudes easier to debug if you write the same system in BEAM native