> The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it

But that's exactly what OP was talking about. Maybe for you that doesn't mean Go fails here, but for (us) Scala developers it definitely feel like Go fails us. We want a language that fails at compiletime in as many cases as possible.

> But that's not much of a point if it's not a real problem in practice.

Maybe not for you. For me it is!

I agree it's fine to have different taste, as I mentioned in another reply to you.

But it's the difference between whether this statement is objective, or subjective.

> is the best concurrency library on any platform

Fair enough, that sentence is a bit over the top. I personally agree, but it is subjective and sounds like a fact.

Not a real problem in practice is just another way of saying rare. But given enough scale and enough time, rare things do happen, and they cost inordinately more programmer effort to chase down. I actually don’t mind if the compiler lets me ship very dumb bugs: those will be auto-rolled back out of production in seconds. It’s the subtle stuff that kills me.

Error handling and Go doesn’t mix well.

That's a matter of opinion. Many, me included, very much like the current, very explicit, approach.

I understand why people who like monadic constructs don't like it though.

Not quite: https://www.uber.com/blog/data-race-patterns-in-go/

I don’t know — I don’t claim that algebraic datatypes are the only proper way to handle errors, I’m okay with exceptions as well (even checked ones). But what go has is only very slightly better than C’s attempt, so I’m not sure it is that subjective.

I think the presence of multiple return values and the ability to easily use complex types for errors make a huge difference (adding wrapping messages, context, etc.).

I agree algebraic data types could improve this. I don't think monadic result types or exceptions would be an improvement.