Rob Pike interview
I have huge respect for Rob Pike but there&#x27;s a bit of revisionist history going on here.<p>Go was originally envisioned as a systems programming language. It was often called &quot;a better C&quot;. This exposed Rob Pike&#x27;s lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter.<p>Where Go succeeded was completely unintentional (as as often the case): it was (and is, IMHO) a better Python. Go hasn&#x27;t attracted C, C++ or even Java programmers. It attracted Python refugees. So it&#x27;s no accident the touted use cases (&quot;cloud infrastructure&quot;) are <i>orchestration</i> problems.<p>But at the same time, &quot;cloud infrastructure&quot; here refers to what, exactly? Kubernetes? Etcd? I think those could&#x27;ve been written in anything. More to the point, users of those don&#x27;t really use Go as a result, right?<p>I think even Google found that internally Go was cannibalizing Python usage and little else.<p>Lots of Go newbies bemoan the lack of generics. I was never one of them. It&#x27;s not the problem people think it is (IMHO). I&#x27;ll be interested to see what this solution is even if simply means we can stop having having this conversation about Go not having generics. That alone is a win.<p>So I think there&#x27;s two areas where Go screwed up. two big and one small.<p>The small one is the lack of IDE support. You don&#x27;t need to write an IDE. You just need to have sufficient integration into Jetbrains IDEs (at a minimum).<p>The first big problem--and it still is a problem--is the dependency management, in that there wasn&#x27;t a solution to this out of the gate (unlike, say, Rust and Crate). Like I was shocked the first time I saw import &#x27;github.com&#x2F;some_random_user&#x2F;...&#x27; I dare you to go look at any even moderately sized Go project and unravel the levels of dependencies (including repeated dependencies, which may or may not impact binary size, I&#x27;m not sure). It&#x27;s kind of a mess.<p>The second is, oddly, on concurrency or rather multi-core and multi-CPU utilization. Aren&#x27;t we still in the GOMAXPROCS environment variable era? Really?<p>EDIT: adding this quote from Rob Pike in 2012 [1] as it&#x27;s a first-hand account of Go&#x27;s original design goals:<p>&gt; I was asked a few weeks ago, &quot;What was the biggest surprise you encountered rolling out Go?&quot; I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.<p>[1]: <a href="https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponentially-more.html" rel="nofollow">https:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponenti...</a>