I'm always impressed by how effortlessly this claim of the extraordinary readability of Go code is thrown around by the language's apostles, given how substantial that claim is, and that it's only backed up by anecdotal arguments with no context about things like the problem solved or the size of the code base involved.

Simplicity is a good thing. Oversimplification in fundamental spaces like the framework for expressing your ideas is a tempting, seductive short-term win that will squeeze the life out of you when it's too late.

Here are some ways in which Go code is harder to read and reason about it because of the language's low capacity for abstraction:

* The need to inspect loop bodies to understand which simple algorithm is being used. Is it a sum, or a find?, or something more complex? Well, let's look for all the ifs and breaks and accumulators, and reason about it, before we can be sure.

* The difficulty in verifying guarantees about your program, for example ensuring that the caller doesn't append to a slice passed to a function if we want to append to that slice ourselves.

* The tendency to have logic spreading multiple screens vertically, because of verbose error handling, and data transformation. You need to keep a part of a function in your short-term memory in order to understand the whole (or zoom out and get a magnifying glass).

* The difficulty of managing and verifying the correctness of concurrently executed code. A wait group needs to be incremented with the number of the joined goroutines manually. There's no abstraction over common operations, like merging channels, and their manual implementation is error prone and complex.

* The need to roll your own implementation of menial tasks, like cloning a map, or getting a list of map's keys. This introduces distractions into the code, almost meaningless sections of it that nevertheless need to be understood and classified as unimportant by the reader, and take up precious visual field.

* No support for immutability makes it less obvious to the reader which parts of the gadget they're looking at can move.

* Almost every more sophisticated data structure needs to have a custom implementation, that needs to be audited for bugs.

I think this belief in the readability of Go code might come from the misconception that if a tool that you use to build something is simple, the resulting thing will be simple too. I can forgive that mistake, but the misconception has to be cleared up. We can't have unsubstantiated arguments about simplicity till the ends of time.