I hesitate to say I thought this was a good article because it was highly negative and I don't think it focused enough on the positives (of which I think there is some - for example, it has very nice and highly performant lightweight threads with full blocking semantics via goroutines). That said, I'm not really a fan of Go even though I wrote it for a few years and I think the article covered pretty well why I don't generally care to write it (even though I don't agree with everything they said).
I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language, but not the choices they made. I like the idea of simple tooling, but don't find their tooling simple to use (ironically, Rust's tooling is much simpler to use IMO). By being less expressive, it actually makes it more confusing to use IMO (in the same way I find dynamic languages more confusing because without static types, I'm less sure about what args a function takes). By keeping null, not having sum types, etc., I don't trust the code I write. In the same way I don't trust any code I write in Python unless covered by a test, I don't get much confidence in Go's static typing due to their implementation choices.
In summary, I don't think 'simple' is the right metric because it doesn't necessarily make writing code 'easy' or safe. For me, languages that are highly 'logical' and 'compose well' are much easier to use in practice. A language should try and find the simplest way to express X, not remove X as a concept IMO, or else code simply will not scale or compose once past a few thousand lines.
I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language, but not the choices they made. I like the idea of simple tooling, but don't find their tooling simple to use (ironically, Rust's tooling is much simpler to use IMO). By being less expressive, it actually makes it more confusing to use IMO (in the same way I find dynamic languages more confusing because without static types, I'm less sure about what args a function takes). By keeping null, not having sum types, etc., I don't trust the code I write. In the same way I don't trust any code I write in Python unless covered by a test, I don't get much confidence in Go's static typing due to their implementation choices.
In summary, I don't think 'simple' is the right metric because it doesn't necessarily make writing code 'easy' or safe. For me, languages that are highly 'logical' and 'compose well' are much easier to use in practice. A language should try and find the simplest way to express X, not remove X as a concept IMO, or else code simply will not scale or compose once past a few thousand lines.