I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning.
More to the point, I don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...
The drop in performance isn't just while learning. I worked somewhere where I had to regularly use TCL, Java, PHP, C++ and Python - each was the most suitable tool for the job (at the time the tool was written anyway) but the constant context switching caused a real and permanent performance hit.
> but the constant context switching caused a real and permanent performance hit
Maybe context switches were too frequent? Or the opposite, too rare, which could lead to repeating the learning overhead each time? Personally I didn't notice any slowdown due to switching between languages and technologies - other then at the beginning, when I was learning them.
For me, it's the infrastructure & best practices that's the biggest cost.
There are degrees of language learning. I went through a "everyone should be a polyglot programmer" phase when I had about 3-4 years of experience, because I was then proficient - not expert - at about a half dozen languages. At that point, I knew the syntax and semantics of all of them, the common standard library calls that I needed for everyday programming, and most importantly, I could mentally map between constructs in my head. So I'd be like "This is a 'for x in collection' loop in Python, a 'for (String x : collection)' in Java 5, a 'for (var x, i = 0; x = collection[i++];)' in Javascript', a 'map (\x -> ...) collection' in Haskell".
I'm coming up on 10 years of experience now, and I try to limit the number of programming languages I work with pretty dramatically now. What's changed is that I now think of a language as an ecosystem and a culture, rather than a set of things I type into a computer. The typing is automatic; instead I'm thinking of the level of "Well, if I use Mockito and JUnit for my unit testing, here's how I have to set up my Dagger modules, and I can use Providers there to give me a dependency graph of ListenableFutures that will let me kick off a whole cascade of RPCs when a request comes in, all without having to manually manage the sequence of events." And all of those libraries have gotchas and best practices that I've internalized, which I think need to page out if I start working with another ecosystem. (This was perhaps a bad example because I'm actually much more fluent with Python and Javascript than Java now - but then, maybe that makes it a good example, because it shows how much tacit knowledge is important even for a simple forum comment, let alone a working system.)
So I can't really judge your level of expertise over the Internet. But I'll caution you that views on this can flip-flop as you gain more experience. It's important to really learn one language well before judging that everybody should be able to use multiple languages with equal proficiency. "Learning them" is a continuous process, and there're tips and tricks that are very specific to each language that you continue learning even decades in.
Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.
More to the point, I don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...