[raphael_kimmig]

It's interesting that the resulting go code has 43k lines of code, while the python client for raven only has 6k lines. I don't know whether they have equivalent feature sets - but I kind of wonder how it would have turned out if the go port would have been based on the python version.

[user5994461]

Python is a much more concise language. There are no brackets/parenthesis to surround blocks, that's 10% to 20% less lines just for that. A truckload of data classes and static declarations don't need to exist in python because of its very dynamic nature. Last but not least, python idioms like list comprehension and single line if else can replace a whole code block from another language.

Expect a python program to be half or a third of the size of java/c#/go.

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

[ayende]

They are pretty much equivalent, feature wise. However, the Python client gets away with a lot less code because of the dynamic nature.

Another reason for the difference is that the Java client is actually considered to be the primary one, which all the other ones are based off.

The Python client is missing a fair number of tests, though.

[pknopf]

That probably has a lot to do with the error checking in Go.

[weberc2]

I’m sure that’s a good chunk of it. Go also lacks list comprehensions, so you have a for loop instead. Go has more boilerplate, but not more complexity.

[stefano]

Boilerplate is complexity.

[pknopf]

Idk, you are arguing that more lines of code equal more complexity.

[weberc2]

No it's not, by definition. :)