[dkarl]

I don't think the tradeoffs made by Go have been explained in a way that makes sense to people who find value in the techniques and idioms described in the article. I agree, if Go lacked these features because they were consciously traded away for something else of value, then it would only be half an argument to point out that they have value.

It would only make sense to make that point if they were intentionally left out of Go because they were regarded as having no significant value or even negative value. And that, I think, is the widespread perception of why they aren't supported in Go.

We can accomplish a majority, if not all, problems in a language, but this shouldn't assumed that a language is intended to do so.

The programming methods described in the article can be applied to almost any problem that Go is a good fit for. If that's in question then I think it proves my original point — this argument is not about arguing the tradeoffs; it's about whether anything of value was left out.