Refutation: Go's Design is a Service to Experienced Developers

Reference:  Why Go’s design is a disservice to intelligent programmers

I honestly can't decide if this article is sarcastic praise for #golang hitting every one of its design goals, because once you look past the ad-hominem crap, it's there:

• "Similar to Go, the book is easy to read with good examples and clocking in at about 150 pages you can finish it in one sitting." 
  • Read: Go's easy to learn.  The documentation is excellent.
• "I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?" 
  • He misses the point entirely.  Those same devs choose to go away from the frills to get leaner and faster.  Code is a means to an end at Google, and they realize that it's going to be read by other developers many times more than it's written.  Simplicity and clarity surmount all else; Google's stultifying C++ style guide makes this apparent.
• "There are no shortcuts in Go, it’s verbose code or nothing."
  • Shortcuts get abused.  See: C preprocessor macros.
  • I read this as "'I have to check return values and handle errors' == verbose code."  This is not a valid Software Engineering view.  IMO, it should be obvious whether code handles errors properly.
• "The language could be described as C with training wheels."
  • Thanks!  I rather like C.  I just wish it had a decent Standard Library, no header files, less "undefined" behavior, inbuilt concurrency, package management, and garbage collection. 
  • Oh wait, that's Go.
  • Obligatory:  Java is C++ with training wheels.  That worked out rather well.
• "Their recommendation was to just copy the entire repository at that time into your project and leave it as-is."
  • This is known as 'vendoring your dependencies', and it's a common practice.
• "There is [sic] no new ideas in the language apart from the concurrency support (which is excellent by the way) and it’s such a shame."
  • Unsupported assumption: Something must contain new ideas to be valid.
  • "Concurrency support...is excellent."  Yes, it is.  Loads better than the shared-state locking pthreads crap we've dealt with for 20 years.

Every fact in this article--aside from Generics--points to Go achieving its design goals.  In a very backhanded way, TFA supports why people writing server-side code at scale should consider using Golang.

* * *

The summary demonstrates so many problems in our industry right now:

[Go] has been written for lesser programmers using an old language as a template.

Fellow programmers, can we get over ourselves, please?  To categorically refute the above:

1. On any given day, we're all lesser programmers.  For my part, I'm certainly not on all cylinders on 3 hours' sleep in the middle of crunch trying to ship product.  It's no sin to want code that's easy to reason about when you read it.
2. Choosing something easier to read and sustain does not make you a lesser programmer any more than choosing to read Hemmingway in lieu of Shakespeare.
3. Ah: 'using an old language'.  This is the heart of it.  'Go' isn't cool, so let's set it aside.

I find the above exasperating, simply because it's the same naïveté that's led to 1000 JavaScript Web MVC Frameworks, LISP fragmentation, etc.   

As Software Engineers--if such a PE-worthy profession ever emerges--we must surmount simple fad and fashion and entertain what's useful, evaluating on merit alone.