> Indeed, you can end up with an indeterminate state. No. I think that claim is hysterically funny considering that Go developers almost never check all FOUR s

> Indeed, you can end up with an indeterminate state. No. I think that claim is hysterically funny considering that Go developers almost never check all FOUR states of Go's style of error handling. The problem Go is solving here wouldn't even exist if they had designed/used a better language in the first place. Maybe Go people should stop drinking so much Kool-aid, because they sound like all these Node.js-ninja-rock-star kids who think that they revolutionize asynchronous programming while they reinvent threads, badly.