As someone who thinks readability is the¹ most important quality of source code, that makes me less interested in learning Go.
¹ Yes, even over correctness.
¹ Yes, even over correctness.
Correctness is a basic starting point. It's the minimum viable offering.
Here is my counter argument.
Readable code that has some bugs is fixable. Because you can understand what it's doing and how to change it.
Working code that is unreadable is basically dead. No one can make changes to code they don't comprehend. The only thing it's good for is running it as is, much like a compiled binary.
The argument that "all code gets sloppy so let's just have very verbose code from the get-go" is pretty insane to me.
How easily can people understand what this code does and how?
This is at least conceptually objectively measurable, though I don't know of any actual attempts to do so.
That's why things like C coding style is so variable - sometimes within the same body of code (see net-snmp ....)
I'd rather have consistent coding standards but I daily deal with different team projects with different conventions, so I'm used to adapting my own reading conventions as I switch contexts.
Keep a common aesthetic within a project. It's worth it - by measure of success of a project.