Ask HN: Java Suffers from an Identity Problem | Hacker News Reader

Ask HN: Java Suffers from an Identity Problem

3 pointsitsmefaz10 comments

Most of the day to day software engineering is our ability to work with the language tooling, we can also call it the ecosystem of the language. From Java's perspective most of our interaction with the language is not directly with the language but with frameworks like Spring etc. These things are meant to make the language more easily digestible. The problem comes in when the platform becomes so huge that there is no way to logical develop a thorough understanding of the actual technology at hand. I started studying Java again to brush up my knowledge of it but found that the language has grown so much it was difficult to derive a logical conclusion to the platform.

This was further evident when I started looking for Java developer roles in my country and found that just understanding the language and its principles were not enough. There seemed to be a general consensus that Java developers must know other related technologies like Spring, JPA, Hibernate, etc. All these related technologies bring their own software paradigm into the picture and hide the actual technology (Java) under the hood.

* Why for some weird reason a Java developer must know or supplement his understanding of the language with framework like Spring, JPA, Hibernate, etc? This is true for other platforms like Node.JS where you have MERN stack etc.

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

> 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.

Thanks for your detailed assessment of the languages. This has given me a good idea which direction to go towards.

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.

Thanks for your response!

I completely agree with the Big Ball of Mud and Swap guide analogy as that has also been my experience. I am also looking for alternatives and Go seems to be the logical conclusion that I am getting to. What would you suggest?

Java seems to have reached the status of Cobol - it will probably never die and there will be plenty of jobs at large enterprises. But you have to commit to learning about the swamp. The more you know about the swamp, the more valuable you are. There's a lot of money to be made in the swamp.

However, it sounds like you're looking for a situation that is more open to newer approaches. Go is easy to learn. Interview around and see what they're looking for.

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.

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)

Do you happen to know platforms / languages that are primarily built to work on scale both for users and developers? I sense Go has projected itself to be the one, do you have any other suggestions?

Typescript was almost delightful experience for me both on back and front end.

Ruby is another amazing experience of mine. Although it’s limited to web backend tasks and not “realtime” performant - it outperforms any other tool in terms of dev speed and satisfaction.

And in real life you very rarely need “realtime” performance, but it’s much mich cheaper to buy another server than to hire another engineer to deal with java spring mess.

Success of Stripe proves my point.

Reply on news.ycombinator.com