“Go’s design is a disservice to intelligent programmers”

If I wasn't already a Go programmer, reading this would make me more interested in Go than not.

Simplicity is deceivingly challenging, and quite different from simple-mindedness, which seems to be what the author is accusing Go of being.

Keeping code simple, elegant, and consistent is IMHO one of the most valuable principles a team can adhere to. Simple is not necessarily shorter, as short can often be subtle and sneaky rather than simple. Complex power tools can be fun to the inquiring mind, but the ultimate consumers of your product almost never appreciate how you built it, but almost always appreciate the final outcome.

A wise man once said: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian Kernighan

There's also the argument that your chance of writing buggy code increases with each additional line you write.

Highly readable code helps reduce bugs. But if that code is also so simplistic that it necessitates a lot of verbosity, you definitely increase the chance of introducing some stupid bug. Thankfully, as a compiled language, Go can find a decent portion of the silly stupid bugs where in a more expressive language like Python they might go hidden for longer, but it's still a big tradeoff you're making.

Go is not significantly more verbose than python except in a couple trivial cases (list comprehensions become a 3 line loop). Across even a moderately sized program, this will most likely not even amount for a statistically significant difference.

Go does seem more verbose than Python. Rosetta code tries for idiomatic solutions to common tasks, here's one such completed in both Python and Go: http://rosettacode.org/wiki/Bitcoin/address_validation

You would need to know the nature of the tasks to pick out those that need longer answers but all the Go tasks are here: http://rosettacode.org/wiki/Category:Go - most of which should have Python solutions.

Most of those programs are trivially small, and often consist mostly of transformative loops. Yes, go will be worse than python for that. But in a real project, the difference will be minimal, a few percent, which will be lost in the noise of the specific implementations, tests, etc.

Even so, Go seems less succinct in comparison on several tasks. Such differences will most likely be magnified in larger programs.