[dcminter]

You're not the only one I'm sure, but sounds like you don't need it. Its major strengths are:

• Bottomless resource of developers with Java experience

• Vast array of existing libraries many of which are enterprise focused

• Managing very large codebases with many contributors is straightforward

• Standard VM that's very solid (decades of development), reasonably fast, and supported on essentially all platforms.

It doesn't have quite the stranglehold (even in Enterprise) that it had in perhaps the early 2000s and it's the archetypical "blub" language, but it's a perfectly reasonable language to choose if you're expecting Enterprise scale and pure performance is less valuable to you than scaling out with large numbers of developers.

I like Rust, but it's Java that puts bread on my table.

[sriram_malhar]

I fully agree with you about the solidity of the VM. The others I am not so sure about.

> Bottomless resources of developers with Java experience.

With Java experience, but what fraction have a systems outlook? What fraction have an experience with other languages to ensure that the code they write is simple and understandable and direct? My own experience is that too many come out addled by Enterprise Java idioms, and when you actually write some code in Erlang or Go you realize systems aren't as complicated as they have been made out to be.

> Managing very large codebases ...

I wonder if this is self-fulfilling. My theory is that these codebases are huge because their designs are enterprisey. The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise.

[plandis]

> With Java experience, but what fraction have a systems outlook?

It depends what you mean by systems outlook but JVM based code is pretty common (to the point I’d say ubiquitous) in large distributed systems.

In open source it’s much the same. Many of the large Apache projects are in JVM languages, for example.

> The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise

The indirection in Java does drive me crazy. But dependency injection is a problem to solve in every language and libraries that can do code generation at compile time like Dagger2 make this predictable, debuggable, and fairly easy to reason about on the JVM.

Microservices are, in my opinion, more of a business organization solution than one tied to any specific language. If you haven’t read Steve Yegge’s blog post about Amazon vs Google I think it’s good reading on why/when SoA is a good idea.

[kaba0]

There are more Java devs out there than people living in my country. I don't think generalizing this way is helpful, there are many different styles of Java development, and developers have vastly different skill sets.