Agree, agree, agree. I've bounced between Python, C++, and Rails in my career, and lately have been ramping up at a Go shop. Go is like C++ in the sense I can tell that eventually I'll get better at eyeballing a file, sensing the shape of the code, and zeroing in on the important bits.

Just like learning to read large C++ codebases, there's clearly a learning curve because a simple idea that would be a one-liner in a high level language is going to be 5-15 lines.

Go also makes the "learn to read" learning curve even steeper when folks pick up and propagate the core team's propensity for single letter variables. I feel like one of the understated benefits of ruby/python/similar languages being relatively readable is that folks are inclined to keep them readable. Whereas when you feel like you're one step away from specifying the register and how hot the welding torch should be to toggle the bits, you're somehow more likely to write `c.T.Client.Send(v)`.

IMO if we accept that most of our work is maintenance & modification of existing code, and most of the work in those tasks is understanding what's already been written, it follows immediately that code that's easy to read has high business value. I know it's too soon in my learning curve, but I'm really hoping I find the patterns that make Go easy to read soon. (and a little tangentially but the descriptive power of a variable name should be proportional to its scope - so imo anything exported or that I might see across multiple files is an awfully strong contender for a multi-word descriptive name.)