The Zen of Go
Here&#x27;s a hot take from a polyglot who does a fair bit of professional work in Go:<p>Go is a low-blub language whose advocates are proud of the fact that they never made it past 200-level CS courses. It&#x27;s the computing equivalent of the blue-collar anti-intellectualism that is rampant in politics these days.<p>Yes, Go the language is simple - it pushes complexity off to your programs instead! Instead of functional expressions, Go programs are pages and pages of iterative loops and variable manipulation. Without generics, you can&#x27;t use even the most basic functional constructs like map and reduce. The most boring mainstream languages like Java and Javascript are adopting functional paradigms, whereas Go is actively hostile to functional programming.<p>Nothing is more tiresome than the continuous prattle about exceptions. &quot;How can you possibly write code that is robust in the presence of errors when you don’t know which statements could throw an exception?&quot; <i>Easily</i>. That&#x27;s the great thing about exceptions, you don&#x27;t need to know about them to write robust code.<p>In general business processing, an exception thrown across a transaction boundary rolls back the transaction. In most cases that&#x27;s pretty much all you need to know. In the case where you need to explicitly rollback a state change (extraordinarily rare in business processing), you add a try&#x2F;catch&#x2F;throw, and you don&#x27;t even need to look at the exception!<p>The fact is, 99% of programs need only one exception handler. In webapps, it&#x27;s the http processor that returns a 500 error. In GUI apps, it&#x27;s the main execution loop that shows an error dialog.<p>Go&#x27;s error handling not only requires endless tedious &quot;if err != nil return err&quot;, but each one of those statements <i>destroys stack information</i>. Folks like to berate Java for long stacktraces, but those stack frames are valuable for debugging. By comparison, Go&#x27;s errors are an opaque bit of text. Third-party libraries can help by wrapping errors in other errors (hand-building stacktraces), but this won&#x27;t help you when using third-party libraries that don&#x27;t use these wrappers.<p>I&#x27;ll say something positive about Go, and why I still use it: It&#x27;s a better C. For low-level-ish code that needs performance and fast startup time (CLIs, simple GAE services that scale to 0 and need immediate startup), Go fits the bill. Having concurrency built into the language is nice, although most other common languages have equivalent facilities in their libraries.<p>But as a language to take over the world: Not a chance.