Earlier quoted context omitted.
The fact that the compiler doesn't cover that automatically doesn't mean Go fails at it, as it has very good primitives for handling them. Error handling and deferring for resource closure work just fine. Sure you could say "but the compiler doesn't guarantee it". But that's not much of a point if it's not a real problem in practice.
> 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…
But it's the difference between whether this statement is objective, or subjective.
> is the best concurrency library on any platform