But Go is not that readable. In fact across all languages I know I would factor go towards the bottom end of readability. Mostly because of it's insane error handling overhead. A lot of function bodies are like reading a book where every sentence is followed with 3 that have no meaning.
The fact that goland automatically collapses error handling blocks is solid evidence that enough developers find go's error handling blocks to be invasive.
I agree. My point is that you can't objectively define readibility, so it will always be a matter of preference. I've met my share of Go developers that think it is very readable. I personally can't stand it.
You don't understand 'readability' the same as the language creators.
More text to read doesn't necessarily make a file or function less readable. Quite the opposite usually.
IntelliJ collapses the repeatedly occurring err != nil blocks with expandable placeholders in grey color to aid readability. Not the ultimate evidence but says something when a commercial product spends effort behind such features.
I don’t know, I understand most assembly line I see in isolation, yet often have no idea what the whole does. Sometimes too primitive primitives actually hinder readability/understanding.
I know many don’t feel that way, but functional stream manipulation is a very good example for that — I much rather deal with filter.map.reduce whatever, than 3 nested for loops with random breaks inside, even though the latter may be easier to reason about line-by-line
Not necessarily no. It's a balance. And Go skews so far that it's no longer reasonable. It's so bad that the most popular Go IDE by default removes the error handling code from view.
That’s a myth. Go read some random Go. Trivial functions often do nothing but call a couple of other functions, check errors and return. But non-trivial functions use relatively less lines for error handling.
