5 ms·

The post is spot on and certainly mirrors some of my own experiences using Go and Java. Java is a wonderful language with a terrible culture. Choosing Go or e

The post is spot on and certainly mirrors some of my own experiences using Go and Java. Java is a wonderful language with a terrible culture. Choosing Go or even Kotlin over Java is liberating because it allows an engineer to escape the cultural baggage that comes with Java. What kinds of baggage? The type of baggage that blindly demands using magical frameworks like Spring and JPA or worse engages in best practices chants as they implement 45 interfaces and create thousands of excess classes because SOLID and DDD said to do so. Yes, I'm exaggerating some but this is a real problem on Java teams. I sincerely hope that a culture adjustment is included in the Java 11 release.

neonate 8y ago
Eric Evans, who wrote the DDD book, is an excellent and tasteful programmer who would never "create thousands of excess classes" or teach anything like that.
- tbenedetti10 8y ago
  Agree with your point and the previous responses. My main point is that the "vocal" Java culture doesn't always treat DDD, SOLID, Spring, etc with a critical eye. My hope is that the culture becomes more pragmatic and open-minded to other approaches.
  - ivan_gammel 8y ago
    Java world is the biggest today and we are talking about mass culture, in which average developer isn't a genius with decades of experience and average employer has only resemblance of modern development process. It will never be the culture of best practices only, so it's actually good that big frameworks exist and they are already mature enough to tolerate misuse. It is this environment of uncritical thinking, the real battlefield, in which best practices are being invented, tested and verified on massive scale, outside the sterile conditions of the perfect teams. It also explains why Java sometimes lags behind other languages in adopting new features, but is still much more popular: not all of those features are good enough to be released in the wild (I wish developers of other languages would actually perform "drunken user" test before inventing crazy syntaxes and APIs).
ivan_gammel 8y ago
Liberation from SOLID and DDD is like liberation from electricity and healthcare system. Makes things simpler, definitely, but doesn't make life better. Throwing away slightly imperfect tools that compose significant part of modern Java software is also quite interesting idea, but what would you use as a replacement (to achieve at least the same code quality and development productivity)?
stephen 8y ago
> blindly demands using magical frameworks like Spring and JPA That sounds like ~2005 Java to me, where the ~whole ecosystem was that way, and consequently a lot of Java devs left for Rails. However, I think in Java's today (since ~2010) there are definitely two (or more camps) of old-school enterprise Java (which is like you say) but also lightweight start-up Java (which is what I'm more familiar with, and matches your "Java can be a great language when used well" comment). So, anyway, IMO, it's not the entire Java culture anymore, although of course I believe you that that is the one you're currently in.
jrs95 8y ago
Honestly, Spring and JPA are largely what brought me back to Java. There's complexity there for sure, but those are very productive tools that are also very flexible. I don't waste much time on configuration, testing (even testing Spring Data JPA repositories) is easy and requires almost no configuration or external tooling, essential things like JSON serialization, request validation, fine grained control over error responses, database transactions, async tasks, and message queues all pretty much work out of the box and just let me get shit done. There might be a lot of overengineering going on under the hood, but as far as my code is concerned there's little to no inheritance and even interfaces typically aren't needed. It's mostly just object composition. And if I didn't want the magic, projects like Dropwizard and Vert.x are there. But I'd rather have the most productive out of the box experience possible.
- hotcrossbunny 8y ago
  I agree with your point about the productivity gains you get out of the box, particularly when starting new. The trouble I find in enterprise development particularly around things like Spring is that the features for which you onboard the framework for at inception act like the thin edge of the wedge. A couple of years in, and perhaps a few maintainers later, Spring is somehow running the show, and a huge source of non-essential complexity. How to limit the scope of use of an on-boarded framework to just its original remit seems to be the challenge.
pjmlp 8y ago
You are speaking about enterprise culture. It was already like that with C, C++, Smalltalk, Delphi, VB before Java came around. Rest assured there will be GoEE and GoSpring if enterprise architects ever put their hands on Go for the same kind of scenarios.

neonate 8y ago

Eric Evans, who wrote the DDD book, is an excellent and tasteful programmer who would never "create thousands of excess classes" or teach anything like that.

tbenedetti10 8y ago
Agree with your point and the previous responses. My main point is that the "vocal" Java culture doesn't always treat DDD, SOLID, Spring, etc with a critical eye. My hope is that the culture becomes more pragmatic and open-minded to other approaches.
- ivan_gammel 8y ago
  Java world is the biggest today and we are talking about mass culture, in which average developer isn't a genius with decades of experience and average employer has only resemblance of modern development process. It will never be the culture of best practices only, so it's actually good that big frameworks exist and they are already mature enough to tolerate misuse. It is this environment of uncritical thinking, the real battlefield, in which best practices are being invented, tested and verified on massive scale, outside the sterile conditions of the perfect teams. It also explains why Java sometimes lags behind other languages in adopting new features, but is still much more popular: not all of those features are good enough to be released in the wild (I wish developers of other languages would actually perform "drunken user" test before inventing crazy syntaxes and APIs).

ivan_gammel 8y ago

Liberation from SOLID and DDD is like liberation from electricity and healthcare system. Makes things simpler, definitely, but doesn't make life better. Throwing away slightly imperfect tools that compose significant part of modern Java software is also quite interesting idea, but what would you use as a replacement (to achieve at least the same code quality and development productivity)?

stephen 8y ago

> blindly demands using magical frameworks like Spring and JPA That sounds like ~2005 Java to me, where the ~whole ecosystem was that way, and consequently a lot of Java devs left for Rails. However, I think in Java's today (since ~2010) there are definitely two (or more camps) of old-school enterprise Java (which is like you say) but also lightweight start-up Java (which is what I'm more familiar with, and matches your "Java can be a great language when used well" comment). So, anyway, IMO, it's not the entire Java culture anymore, although of course I believe you that that is the one you're currently in.

jrs95 8y ago

Honestly, Spring and JPA are largely what brought me back to Java. There's complexity there for sure, but those are very productive tools that are also very flexible. I don't waste much time on configuration, testing (even testing Spring Data JPA repositories) is easy and requires almost no configuration or external tooling, essential things like JSON serialization, request validation, fine grained control over error responses, database transactions, async tasks, and message queues all pretty much work out of the box and just let me get shit done. There might be a lot of overengineering going on under the hood, but as far as my code is concerned there's little to no inheritance and even interfaces typically aren't needed. It's mostly just object composition. And if I didn't want the magic, projects like Dropwizard and Vert.x are there. But I'd rather have the most productive out of the box experience possible.

hotcrossbunny 8y ago
I agree with your point about the productivity gains you get out of the box, particularly when starting new. The trouble I find in enterprise development particularly around things like Spring is that the features for which you onboard the framework for at inception act like the thin edge of the wedge. A couple of years in, and perhaps a few maintainers later, Spring is somehow running the show, and a huge source of non-essential complexity. How to limit the scope of use of an on-boarded framework to just its original remit seems to be the challenge.

pjmlp 8y ago

You are speaking about enterprise culture. It was already like that with C, C++, Smalltalk, Delphi, VB before Java came around. Rest assured there will be GoEE and GoSpring if enterprise architects ever put their hands on Go for the same kind of scenarios.