[skj]

With big python projects it's often difficult to figure out what code is going to be executed next due to inheritance and mix-ins.

With Go, it's usually pretty straightforward. Yes, there are interfaces, but they're used in places where people actually want the choice of code to be dynamic, rather than people just having fun building up crazy hierarchies in the name of DRY.

So, with Go I find it very easy to read because of high code locality and the ease of following to the correct destination with function calls.

For things that are already local, "ease of reading" is just code for "familiar". Go is strictly easier to read because tracing through is strictly simpler. Anything else is just spelling and those barriers disappear with only minimal experience.

[joshuamorton]

This is true for particular types of python, but not true for most of the python code I work with, for example. I'll grant you "encouraging non-complicated architecture" is a good thing, but Go swings a bit too far in the other direction, for example `set(foo) - set(bar)` in python is an extremely expressive (and efficient) way to give me the things in foo that aren't in bar.

In go, you can either do this as a nested for loop, which is harder to read and n^2 instead of n, or explicitly loop over each iterator and convert to a map (which, to be fair, is exactly what python does too), and then write the map-diffing yourself, which is easy to screw up and should probably be thoroughly tested to ensure you didn't make any mistakes in your implementation.

In python its one line of clear, expressive, known-to-be-correct, code. Granted the generics proposal should do a lot to improve things here, but I disagree that go is "strictly easier", because there's often far more to trace through, as there is far less abstraction provided for you by the language, so instead of having to perhaps unwind a single complex expression that uses some advanced language features, you have to unwind the pseduo-reimplementation of those abstractions in the local project.

[unscaled]

I think you can summarize the go flavour of "readability" as:

Fewer constructs for the price of higher Signal-to-Noise ratio.

Go eschews almost any kind of syntactic sugar that might be unfamiliar to you.

The endemic "if err != return err" issue is also highly indicative of this choice.

I really find that quite hard to stomach. For small apps, this can be acceptable, but for any Go app that gets large enough, this trade-off becomes untenable. You have to scan through too much visual noise to get a clear understanding what the code is doing.

[dcow]

Go is a language for writing microservices that handle http requests and/or client-side networking "clients" to an api served by said microservices. My guess is the tradeoff is okay in 95% of those scenarios.