[sheeshkebab]

go codebases are not shorter (by much) than java's.

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.

[dallbee]

Like with all languages the implementer matters. There's a remarkable amount of variance that I've encountered in the tersiness of both Go and Java code.

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.

[_0w8t]

This pattern is known in numerical computing as NaN. It’s drawback is that when the computation produces NaN, one has no idea what triggered it. But that can be mitigated if the program prints stack trace on the first NaN. In case of Go that corresponds to logging error when it happens.

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.

[rsynnott]

If anything, I’d say that due to a lack of generics, and more verbose exception handling, go codebases tend to be somewhat longer than java ones.

[sheeshkebab]

Go error handling is a little bit more verbose, although I find it more readable and consistent than checked exceptions in Java, that everyone seems to find a way to abuse or ignore (wrap into catch all).

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

[adamnemecek]

> generics are not used that often in production codebases anyway

no.

[apta]

> go codebases are not shorter (by much) than java's.

They're usually longer. See: no generics, error handling, among other things.

[hactually]

what do generics have to do with making it longer?

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.

[apta]

> what do generics have to do with making it longer?

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.

[svick]

Except Java's method that does the same (Math.max) does not use generics and instead has overloads for the various numeric types it supports.