That's really strange to me because I find go to be very readable. There are so few approaches to each of the basic programming building blocks in go that once you have read a moderate amount of idiomatic go, everything else just feels easy.

There are far more readable languages in go. Go also encourages nested conditionals which can become a nightmare to trace when you're under duress.

Maybe I'm missing something but Go _discourages_ nested conditionals. There are even static analysis tools in the idiomic toolkit which tell you when your conditionals can be simplified.

No it doesn't, quite the opposite actually. Go favours "exit early" strategies

I'm only responding to my parent post's arguments. I don't know much about Go myself.

This philosophy is about as far from what I value as it's possible to get. An easily understandable program that doesn't solve the problem is worth absolutely nothing. In fact, if it's code someone is depending on it's probably worse than no code at all. In some applications it could even cost people their lives.

Correctness is a basic starting point. It's the minimum viable offering.

That's the most common opinion, and the one I used to hold.

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.

That old adage, the best code is the code not written. Programs have to solve a problem to be worth anything.

I'm firmly in this camp as well. A strong code quality metric is how easily understood something is - we write code in all sorts of states of minds at all hours of the day. If others can read your code and understand it, it means you can too when it's time to extend/modify it. This is also why things like Ruby's over reliance on metaprogramming bugs me - sometimes duplication is fine, and I'd much rather have some duplication than a wrong (or hard to discover) abstraction.

The argument that "all code gets sloppy so let's just have very verbose code from the get-go" is pretty insane to me.

aesthetics are relative, not absolute.

Readability to me is about clarity, not aesthetics.

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 important. But why I say relative - is because the structure and language of readability is dependent on the code culture one is working within, not an outside measure.

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.

This might be bad for maintaining a lively argument in this thread, but I fully agree with that.