[jjav]

> My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA

You state how you don't really use java, but the above confirms it.

Java debugging and diagnostic tooling is second to none.

[toprerules]

That's a really narrow view of the world, and I think another Javaism to think that Java is the entire world. Today's multi-service deployments run tens if not hundreds of auxiliary processes not using Java. They use network overlays that change how processes interact with the network core. A person who is debugging a knock on effect issues has to be able to look through many different layers of processes, many of which are written in C, C++, Go, etc. Having to learn an entire toolset to debug Python or Java is a huge burden and it makes introspection extremely difficult. Java essentially wants to be the entire platform, which isn't how the world works anymore.

[vips7L]

Don't you think a narrow view of the world is this idea that you should be able to use one tool to debug everything? It seems like you want GDB (and the unix's where it runs) to be the entire platform.

[jjav]

When you need to debug across the entire system and into the kernel, I'd use dtrace which has had java stack frame support since... I don't remember anymore, but closing in on 20 years.

[toprerules]

No one uses dtrace anymore. bpftrace is integrated into the kernel and can extract btf type information embedded into the kernel binary.

[bcantrill]

Your (absurdly) broad claim is false -- and it's very easily disproven.[0]

[0] https://ahl.dtrace.org/dtrace-conf-2024/