Ask HN: Java Suffers from an Identity Problem

Java is just an old boring legacy swamp. Back from the days when nobody cared about devx.

Not even close to nodejs, even though js infra is far from perfect too.

But you can’t avoid the need to build hundreds of reused libraries when you build anything bigger than hello world.

It’s just some languages care about your comfort (like Ruby) while others - dont (like Scala)

I remember primarily working in Java when it was the one main choice you had. People were actively looking for alternatives, and then Spring came along and saved it from the archonauts. But the counter revolution by the archonauts ended up pretty much as you describe - layers of sophistry. Java is kind of like a really old city, built upon many layers of cities that predate it. Witness the recent log4j debacle. There's so much complication buried amongst the layers, that something as obviously bad as log4j escapes notice. Even the author of log4j abandoned it many years ago to create logback and slf4j. So, just with logging, there is the standard logging (which nobody uses), log4j (hopelessly complicated), a few others, and then slf4j/logback. Even doing logging in java is a choice fraught with peril.

Come to think about it, the Java ecosystem now resembles more of a Big Ball of Mud (http://www.laputan.org/mud/), where being a swamp guide is more important than other skills.

These days I primarily work in go, and the reduction in cognitive overhead to get things done is immense. Its a language that learned from the mistakes of many others, and gets many things right.

> Are there other languages (or platforms) like Go or Rust where the language is well developed that these external dependencies are minimal.

Seeking a language with minimal external dependencies is futile. Real world work almost always involves a substantial collection of dependencies regardless of the language. Gone are the days when the language has everything you need built-in; that went when the network and myriad protocols appeared.

Compared to Java, Go is generally 'simple' in the sense that it doesn't involve a lot of programming complexity created by the dependencies. There are no macros, annotations are few; mostly you just deal with the language itself and the APIs of dependencies. I really like that aspect of Go and I think it is closest to what you have in mind. Wading through error handling boilerplate is no fun though; easily the most tedious part of Go.

Rust is similar to Java in that you find yourself using dependencies that 'decorate' the language with annotations and macros that add capability and complexity. Many of these dependencies are well designed so the annotations and macros are straightforward to use and easy to live with. Others are mystifying and obtuse. Incompatibilities abound; stable vs nightly, Tokio vs std::async, etc. Rust can be a struggle.

I feel like you're making too big a deal over the commonly used Java stack dependencies. Spring is ubiquitous; there are all manner of resources to help you figure things out and when you understand it and stay between the lines it's fine. Add Lombok (a curated Spring dependency) and writing Java is fairly pleasant and highly productive. I can't speak to Hibernate; I've been fortunate to be able to mostly avoid ORMs. The little experience I've had with Java ORM only encourage that tendency.

It depends on what applications you write. I write financial applications with Java but I don't use Spring and JPA/Hibernate. Spring is quite suitable to write CRUD applications.

You either have a bloated runtime or you need to include more external dependencies. It's just trade off. The trend is to have lightweight runtime in cloud era.