4 ms·

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

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 8y ago
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-by-eliminating-errors 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.
- fpoling 8y ago
  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 8y ago
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 8y ago
  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 8y ago
    > generics are not used that often in production codebases anyway no.
apta 8y ago
> go codebases are not shorter (by much) than java's. They're usually longer. See: no generics, error handling, among other things.
- hactually 8y ago
  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 8y ago
    > what do generics have to do with making it longer? Code duplication, just one example: https://godoc.org/github.com/cznic/mathutil#Max 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 8y ago
      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.

dallbee 8y ago

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-by-eliminating-errors 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.

fpoling 8y ago
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 8y ago

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 8y ago
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 8y ago
  > generics are not used that often in production codebases anyway no.

apta 8y ago

> go codebases are not shorter (by much) than java's. They're usually longer. See: no generics, error handling, among other things.

hactually 8y ago
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 8y ago
  > what do generics have to do with making it longer? Code duplication, just one example: https://godoc.org/github.com/cznic/mathutil#Max 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 8y ago
    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.