[virmundi]

I find Spring to be great. I grant that I've used it since 2.0, but really it does everything quickly, easily, and is well documented. Especially with Spring Boot.

I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the functions, or use closures that define all of your routes in such a way as to make the db visible.

Even if you get past the difficulty of hiding everything, it's oddly not a good language for web services. The handler interface in mux doesn't allow you to return an error! No error in GO! So you're either going to have a tonne of boilerplate for the routes, or use panic, which by all the reading I've seen is a terrible thing to do. Regardless of which you choice, Go appears to lack the niceties of prebinding the JSON into a struct. Boilerplate. Oh, and you have to do the same to write the JSON out!

Now Java allows for annotations, and types with constructors in the input parameters of the route handler. Spring will inject interface implementations by name or type. All of this and Transactions! It will automatically bind the JSON to the input variable and automatically create the JSON format on the return.

Ever tried to use transactions with Go? You have have to personally keep track of it. Every SQL call has to peg against the transaction because the connection pool won't manage it for you. Also the DB and Transaction structures have the same general interface, but DON'T implement a COMMON INTERFACE! That idea, in 2018, is an experimental feature that MIGHT NOT GET PICKED UP. The maintainers of the standard SQL library said figure it out for yourself.

Really, I don't think that Java brings that much complexity now. It use to. But you can get a new developer up and running in Java within 2 months. It will be better structurally, easily testable, and safer than Go.

Go is like a tricycle. It's simple and it will get you there, but doing anything complex will require a lot of effort. Java is like a 10-speed Schwinn. Fast, moderately complex, but easily understood when kept within the wheelhouse of Spring + Core Language.

[flukus]

I don't use go but some of your more general complaints sound like good things to me.

> Regardless of which you choice, Go appears to lack the niceties of prebinding the JSON into a struct. Boilerplate. Oh, and you have to do the same to write the JSON out!

The more time I spend doing maintenance the more I've learned to love this sort of boilerplate. It makes it much easier to trace where things are being used across the system, no reflection magic that causes the trail to run cold and forces you to use a debugger. I know programmers hate writing boilerplate, but it really isn't so bad and makes maintenance that much easier.

> Ever tried to use transactions with Go? You have have to personally keep track of it. Every SQL call has to peg against the transaction because the connection pool won't manage it for you.

Again I like this explicitness and don't want this hidden. Whether I'm operating inside a transaction scope or not in a given piece of code should not be a mystery.

> Also the DB and Transaction structures have the same general interface, but DON'T implement a COMMON INTERFACE!

I agree that a common interface might be nice, but given that there is seldom a good reason to operate without some kind of transaction is it really that big a deal? Just always use the transaction interface.

[sbpayne]

YES. 100x yes to this. I started a new job some time ago where Java / Scala were mainly used (prior C++ background).

I can logically step through flow control and figure most things out. Except the amount of "magic" for the sake of reducing boiler plate made debugging some issues really tricky.

Anytime I'm about to reduce boiler plate somehow, I try to ask myself whether it's going to introduce some type of tribal knowledge. That is, will someone without any knowledge of e.g. this codegen be able to step through and understand what's going on.

I feel that people reduce boiler plate without constraints far too often

[zenhack]

Also, if you really want to write code that's agnostic to whether you're working directly on the DB object or a transaction, you can just declare that interface yourself; it's not like in java where the implementing class has to opt in.

The absence of the interface being predeclared for you does mean more boilerplate, but I agree that transactional vs. not doesn't strike me as a good thing to be hiding; this particular case seems like maybe a very reasonable omission. I try to avoid abstractions that leak.

[kamaal]

>>Really, I don't think that Java brings that much complexity now. It use to.

That's because these days you don't learn Java, you learn things that manage Java madness. Like Eclipse, IntelliJ or Maven etc.

You don't really do much using Java these days. You do things using tools, which write bulk of the Java code. In essence learning Java today is learning Java ecosystem tools.

>>But you can get a new developer up and running in Java within 2 months.

That's because it doesn't much time to learn the IntelliJ UI :)

>>Java is like a 10-speed Schwinn. Fast, moderately complex, but easily understood when kept within the wheelhouse of Spring + Core Language.

This is true for most languages today. Java owes much of its success and power to two things. Libraries and Marketing. Marketing money is gone as Oracle doesn't spend a dime on anything that doesn't bring in two in return. And other language ecosystems have caught up with libraries.

So you could use anything instead of Java and it would all still work, in fact in most shops it already does. Haven't heard any major project being started in Java in most places in a long time.

Legacy projects will carry the Java carcass for a lot of time. But If you want to work on projects worth working, Java isn't the language you should be with right now.

[virmundi]

What you do see is people abandoning the "prototype languages". At least twice a year HN has a story where some company dropped Python, Ruby, etc. in favor for Java. They didn't just port to the VM for Jython or JRuby. They re-made the whole thing in Java.

Why not skip this step and just use Java. Yes, there's great tooling that makes Java easy to use. That's the point. You don't have to use JavaBeans for JSON. Expose the properties as public. Jackson's got your back.

Fundamentally, a good design has bounded contexts. The web API should not directly expose your domain objects to the Internet. There should be a mapping between the service boundary to at least the use case boundary. Exposed properties are find for DTOs like JSON bodies. Map those to your domain objects via a translator and you're good. A lot of bulk drops with this approach.

As a language, yes Java is a bulky. But it's wonderfully readable. I know what type a variable is without having to dumpster dive into the method invocation (looking at you Python and Go). I can know directly through a type hierarchy which components implement an interface. In Go you have to explicitly set the supposed implementation to a throwaway variable just to have the compiler tell you if it works. Yes, checked exceptions are a pain. We know that. When it came out, it was a theoretical good. Unlike Go, at least you can wrap a checked exception with a runtime and move on with your code.

To this day Java is the balanced language between performance and usability (along with C#). It is showing its age. It does need some renovation, but on the whole it's a fine language to do new things.

[pjmlp]

> Haven't heard any major project being started in Java in most places in a long time.

Come to European enterprise shops, Java and .NET rule with no signs of changing.

Including greenfield projects.

Even alternative JVM and CLR languages are hardly an option.

[tomohawk]

I big part of learning Go, once you've done a lot of Java is to unlearn the things that you had to do as a successful Java programmer. You're used to looking at problems through the lens imposed by the imposing bag of tools and abstractions that is Java, as well as obsolete language design decisions (I'm looking at you, inheritance).

Resolve to look at things and think about things differently.

I have to give credit to Spring for saving Java from itself for a while, but it jumped the shark at some point. I've talked to many devs who've come from teams where only a small number of people understood the magic going on, and they never felt like they could really contribute because they couldn't scale the complexity hurdle of the modern Java environment.

[oblio]

This doesn't seem a Java-oriented criticism:

> I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the functions, or use closures that define all of your routes in such a way as to make the db visible.