Performance is also usually on par - unless java's equivalent is built around a lot of reflection (orm and what not).
However, go compiled binaries are usually smaller, and code IMO is much more readable.
For example, Go's err != nil pattern is often cited as being ugly, but good go code will often remove errors by design.
There's a good post by Dave Cheney about this; https://dave.cheney.net/2019/01/27/eliminate-error-handling-....
I think this is equally true of Java. Most Java code I've seen disgusts me, but I've also seen some beautifully written pieces.
Another thing is that in many cases there is no good sentinel value to return that naturally leads to exit from loops or complex logic to check for error at the end of a function.
Go codebases do tend to be a little shorter due to lack of getters/setters... and generics are not used that often in production codebases anyway, relative to all the rest of typical code (that’s procedural anyway).
no.
They're usually longer. See: no generics, error handling, among other things.
If you want to argue 'usually' then you could consider all the build scripts and XML files, class boilerplate and exception code of Java to be 'usually longer'.
Please don't troll.
Code duplication, just one example: https://godoc.org/github.com/cznic/mathutil#Max
Even with exception handling code, Java is shorter. Build scripts are not part of this discussion.