[emodendroket]

Agreed. Even if we buy into the argument that Java is just wordy and slow to work with, once we're doing with long-lived code that needs maintenance, that's less of a concern than code that's hard to decipher, so the trade-off seems like a good one.

[twblalock]

Yep. The wordy nature of Java is just giving you more info to work with when you dive into code you haven't seen before. Java is also a lot less wordy than it used to be, and if you use the right tooling you don't need to actually type everything by hand anyway.

What matters most for maintaining large codebases that a lot of people work on is the type system and the tooling. A large ecosystem of good tooling exists for working with Java, and it is empowered by the static type system to do some very impressive things. Some of the .net stuff is probably close to that with Visual Studio and the ecosystem around it. Everything else is pretty far behind, including Python and Ruby and Go.

I know people who work on a massive Java codebase that is almost 20 years old and has over 1000 people currently working on it -- and thousands more have passed through that codebase in prior years. It's not a lot of fun. But if it was a Python codebase, it would actually be impossible.

[civopsec]

The type system isn’t impressive. You can find usages and thereby get navigation and refactoring via excellent Java-centric IDEs. But it seems like that’s it(?). On the other hand you have to constantly exercise your code because of lurking NPEs. Although hopefully we can get good annotations through third-party tooling (Facebook’s looks good).

[EdwardDiego]

I do like Kotlin's nullable types for that reason alone. At least Java has far better NPE messages now.

https://www.baeldung.com/java-14-nullpointerexception

[emodendroket]

That's a lot on its own, and being able to understand the argument and return types solely by signature is a big productivity boost compared to environments where that isn't possible.

[civopsec]

Java can be hard to decipher in its own way. Mostly because of a culture of favoring just-in-case indirections, a propensity towards making deep call stacks as the codebase evolves (maybe because IDEs make that navigation tolerable, although it never makes it easy to see the whole context), and pretty imperative constructs outside of streams and lambdas.

But on the whole Java is not bad. I think it’s perfectly OK. I am more afraid of Java culture.

[cle]

I disagree that it's a tradeoff, because those two are orthogonal. Java is often hard to decipher because there are many things that can happen dynamically outside the visible code path that affect execution logic, like annotation processing, classloading, dynamic bytecode manipulation, AOP, dynamic proxies, reflection, etc.

[emodendroket]

Most of those strategies are equally popular in Ruby but without the guardrails that at least make them cumbersome enough to make you think "is this really how I want to approach this?" The pitch for Ruby has always been productivity because it's terser so I'm trying to be charitable here and grant them their greenfield case.

[lukeramsden]

In my experience (and our experience at TransFICC building middleware for financial trading systems, which is extremely throughput and latency sensitive), Java is the fastest language to work with simply because the tooling support is second to none.

[commandlinefan]

> code that's hard to decipher

I've worked on a lot of codebases that appeared to be put together by developers who took that as a challenge - IME Java developers LOVE global variables (but they call them "public static" to make themselves forget they're using global variables).