I wasn't saying you should or shouldn't use Go. I was saying that the article you linked to gave a very tepid (but accurate, I think) defense of Go.

Now, your defense of simplicity is a considerably stronger case than was made in that article. That might be true for some people, but I don't think it generalizes to everyone.

Brains don't all work the same. I've tried the simplicity thing, and for me personally, it's a near-endless sink of wasted time. Pointless complexity is even worse, but if what I am doing is offloading something that I do poorly onto a computer which can do it well, the complexity is well-placed.

For instance, I spent a couple weeks struggling with concurrent consensus building between nontrivial state machines in C++ before giving up and using Rust, where I solved the problem in a couple days. (It then took another couple days to integrate the Rust code into the C++ code base, but overall, a win.) None of this was due to C++ being a footgun; it was just that Rust had better abstractions (despite, for instance, its pattern-matching switch statements being technically "more complex") that facilitated the difficult parts of the logic and better guarantees that kept me from making too many mistakes. By the time I got to runtime testing in Rust, the few residual logic errors were fairly transparent in nature, as opposed to C++ where it was always a myriad of mysterious errors. If I had greater cognitive capacity, I could have built the Rust design in C++, having foreseen the possible errors, and structured things appropriately, and manually applied all the equivalences between the Rust design and a not-too-unwieldy C++ variant. But I didn't at that point have that capacity, so Rust was exactly what I needed.

Other people don't seem to have as much trouble as I do with mucking up simple stuff in silly ways, and therefore can actually productively use Python or Go. That's great for them! I think to an extent they have often fooled themselves, because I witness considerable amounts of their own and others' time being wasted on things that would be impossible using languages with stronger guarantees. But the proof is in the pudding, and they do get things done, and maybe they're right that it would have been harder if they'd had to do it some other way, so kudos to them.

Thus, I'm happy to accept a conditional virtue of simplicity for those whom it works for.

But mostly I prefer languages that use their complexity budget to solve important problems that make writing useful (e.g. correct) programs difficult rather than not use the budget at all, and my impression is that people frequently misjudge how much simplicity buys them and discount how much compilers can help them.

(Go's use of some complexity budget on goroutines is, I think, very well-placed expenditure.)