java is very easy to troubleshoot compared to c, go, and rust
All the worst and most time-consuming troubleshooting experiences of my life have involved Java. Whether staring at pages of obscure stacktraces that the JVM decided to vomit all over my screen, or hours on end with Oracle tech support troubleshooting why Java decided to throw a tantrum (followed by editing obscure Java XML config files).
These days I just stay well away from Java.
It's the app whose stack traces you are looking at. And the app that decided to use XML config files.
I really haven't seen all that much XML in Java recently outside of legacy applications... there's libraries for loading config data from JSON, YAML, etc etc.
Google's scale means that performance actually matters a lot versus productivity. When you've got millions of servers the costs add up. So making something twice as fast but taking 25% more dev time is probably a good tradeoff for them. For most other companies that's not the case.
Have you ever heard the phrase "the dog that didn't bark?" You appear to be using an absence of evidence to prove evidence of absence, not to mention an argument from ignorance (which is always possible in our post-Gödel world).
> java is very easy to troubleshoot compared to c, go, and rust
>> Can you expand on this? Why do you think that?
So the comparison is C, Go, and Rust. Yes, I'm familiar with all 3 of them and Java is easier to troubleshoot than either of them because it has better introspection out of the box.
For example, also having experience with all of them, the overall advantage over C is clear-cut but Rust is a lot less clear since stronger type system and better culture around package management and complexity avoids a lot of problems that otherwise require runtime troubleshooting.
Granted, a key part of that is really the question of whether you’re talking about a modern Java project or the more common enterprise Java sort with layers of accreted complexity and probably architecturally frozen at Java 8, where the problem is cultural rather than the language itself.
Consider that you've gotten more useful information from my response than what you've paid for. If you want the whole picture, buy the book. Your sense of entitlement to more of my time seems misplaced.
All the above can be done in other environments, but generally with specially prepared deployments or executables, with choices being made along the way as to how to do it. I think the two key things are that in the JVM the heap is actually a quite structured database, which allows for introspection without recompilation or special tooling, and there's a standard mechanism for exposing detailed performance data.
Whether or not that translates into actual productivity differences is tricky. In my experience large companies tend to build their own equivalent and better-targeted tooling, and smaller companies increasingly pass their performance diagnostics to SAAS companies. It takes time to learn diagnostic tools and procedures in general, and in my experience a lot of Java teams don't know the tooling they have. I'd say the main productivity gain would be in quickly diagnosing production issues. You could argue that the JVM leads to software thinking that increases production issues by relying on long-running processes that need the stability to survive, but in my experience there are definitely niches where that is the only way to meet your performance goals.
I realize, writing this, that for someone unfamiliar with the ecosystem this sounds very abstract, but MBeans (managed beans) are simply counters, operations, stats, faults that the app makes available to other apps/users via a standard protocol.