&quot;So, if Go is as bad as the comments so far make it out to be, what are some alternative languages?&quot;<p>While a good question anyhow, it&#x27;s not as bad as the comments make it out to be. Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives. And the balance shifts depending on what sort of application you&#x27;re writing. There&#x27;s a reason that Go has seen a lot of success writing network servers. There&#x27;s a reason why Go has no penetration into the scientific computing community, and I tend to warn away anybody even thinking about it.<p>In particular, a lot of the people screaming about Go do not consider some of the positives. For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader &amp; io.Writer also already have several test implementations available in the stdlib and it&#x27;s easy to adapt them to a few more), which then allows me to write some <i>really</i> good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) This <i>can</i> be done in other languages, but it often involves jumping through hoops to create your own objects that mirror other object&#x27;s methods so they can implement an interface or something; in Go it&#x27;s trivially easy. Between that and the way errors are handled, I find it relatively easy to write very bullet-proof code.<p>And while I also consider it annoying that Go lacks half of generics (interfaces are actually half of generics, but it&#x27;s missing generic types), there are also often ways of spelling your APIs so it matters less. My code actually doesn&#x27;t end up with very many interface{}s in it, and many of the ones that do are &quot;real&quot;, in that the code in question really <i>doesn&#x27;t</i> care what&#x27;s there.<p>If you don&#x27;t put those positives onto the balance, you don&#x27;t get a proper view.<p>It doesn&#x27;t help that, frankly, this was not a very good article and I strongly agree it has tone issues. This brought out a lot of people who might otherwise have just clicked over without commenting.