Go&#x27;s surge in popularity — and with it, the surge of evangelism — compels people to take a stand, for better or worse. (If Go weren&#x27;t popular, nobody would bother.)<p>I suspect it&#x27;s also partly due to Go&#x27;s curious mix of maturity and immaturity, in an overall promising package with lots of momentum. Here&#x27;s a young language that on the one hand is productive to work with and simple to understand, yet so obstinately awkward and inelegant in several other respects, and represented by a team of designers who aren&#x27;t always saying what many want to hear.<p>It&#x27;s clear that Go was, first and foremost, designed for Google and their need for a natively-compiled, concurrent language that steers the user to a very specific path, largely defined by <i>limitations</i>. Its approach prevents language-theoretic cleverness that can complicate a codebase (think Boost or the STL), and it prevents a lot of foot-shooting and optimistic overdesign that newbies are prone to.<p>But while that&#x27;s wonderful for Google, that&#x27;s also a frustrating to developers who don&#x27;t need this invisible hand hobbling them, and sees Go&#x27;s potential subverted by the stringent design principles. I admit I&#x27;m one of those frustrated by Go&#x27;s type system, for example, or its heavy-handed approach to error handling.<p>Part of the frustration is the lack of a clear alternative: Nimrod doesn&#x27;t have the mindshare, Rust is overly complex and slow to compile, Elixir doesn&#x27;t have the performance, C++ is, well, C++. Go, for better or worse, fills a kind of sweet spot that, unfortunately, also has a dash of sour. And that kind of frustration easily leads to debate whenever Go comes up.