> 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).
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.
JSON, YAML, or XML, it's all the same crap. The fact that programmers are feeling the need to externalise their business logic into "config" files is a sign that the language has failed. In a decent language you would write logic or "config" in the language itself, because the language would be a comfortable medium for expressing things (this is the norm in Python for example - while a few overengineered pieces insist on using TOML or something, most Python libraries don't require any separate config, you just "configure" them the same way you do the rest of your programming, in Python).
well yes... it's a learning curve and it takes a while but if you are familiar with the jvm and xml and to some degree spring-framework and reflection it's usally pretty easy to find a root-cause - you also have great tooling like async-profiler or just sending `kill -3 <pid>` to get a stacktrace. At least you've got a hill to climb upon instead of an empty field.
As an example, this app (Apache Helix) implements MBeans, which means that you can connect to the running application to observe its state and manage it. You can do this with the standard JMX toolchain, without having to implement anything else in the app other than the MBeans.
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.
How extensive is your experience with other toolchains? Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity advantage. Companies like Google with massive Java experience also investing heavily other languages suggests that this is not so compelling.
Being able to off-the-cuff use JMX to do realtime heap and stack analysis and then go deep with an offline heap dump (via Eclipse MAT, for example) is quite nice. On top of it you have a standardized interface for emitting counters and gauges. You can kind of get that through effort with other ecosystems (closest probably being .NET), but with the JVM it's just there and it's standardized. Have a memory leak that takes days of operation to manifest? Set up a trigger to heap dump at a certain time, then open up MAT and you can find some very subtle memory leaks and lock contention issues. Any JVM is basically running in a valgrind sandbox, with enough symbols to support a low overhead gdb connect, with a standard API for emitting meta-performance data.
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.
>Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity advantage
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).
That's a rather pretentious way to miss the point. The question was “Can you expand on this? Why do you think that?” and the response was a sweeping assertion and the name of a couple of products with no further details, or even a clear indication of which of the three languages mentioned further up-thread or others were being used as a basis for comparison. I wasn't asking for a peer-reviewed paper but even, say, “My team had a productivity loss when they switched to Go because [reasons]” would be better than nothing at all.
> 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.
That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience.
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.
> That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience.
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.
>Companies like Google with massive Java experience also investing heavily other languages suggests that this is not so compelling.
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.
Java is extremely old and stable. The obsession with Rust as open-source savior is overwrought. Rust may be good but Java has been around 25 years, give Rust another 10 years and 3 major language revisions before I will trust it.
No, it's not. My experience is that for poor programmers, Java is easy because they lack the fundamental skills, and are familiar w/ the mechanics of Java. Of course this is a broad generalization and terribly unfair empirical anecdata.
