Experience Report: 6 months of Go
I hesitate to say I thought this was a good article because it was highly negative and I don&#x27;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&#x27;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&#x27;t generally care to write it (even though I don&#x27;t agree with everything they said).<p>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&#x27;t find their tooling simple to use (ironically, Rust&#x27;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&#x27;m less sure about what args a function takes). By keeping null, not having sum types, etc., I don&#x27;t trust the code I write. In the same way I don&#x27;t trust any code I write in Python unless covered by a test, I don&#x27;t get much confidence in Go&#x27;s static typing due to their implementation choices.<p>In summary, I don&#x27;t think &#x27;simple&#x27; is the right metric because it doesn&#x27;t necessarily make writing code &#x27;easy&#x27; or safe. For me, languages that are highly &#x27;logical&#x27; and &#x27;compose well&#x27; 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.