I have huge respect for Rob Pike but there's a bit of revisionist history going on here. Go was originally envisioned as a systems programming language. It was

I have huge respect for Rob Pike but there's a bit of revisionist history going on here. Go was originally envisioned as a systems programming language. It was often called "a better C". This exposed Rob Pike'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. Where Go succeeded was completely unintentional (as as often the case): it was (and is, IMHO) a better Python. Go hasn't attracted C, C++ or even Java programmers. It attracted Python refugees. So it's no accident the touted use cases ("cloud infrastructure") are orchestration problems. But at the same time, "cloud infrastructure" here refers to what, exactly? Kubernetes? Etcd? I think those could've been written in anything. More to the point, users of those don't really use Go as a result, right? I think even Google found that internally Go was cannibalizing Python usage and little else. Lots of Go newbies bemoan the lack of generics. I was never one of them. It's not the problem people think it is (IMHO). I'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. So I think there's two areas where Go screwed up. two big and one small. The small one is the lack of IDE support. You don't need to write an IDE. You just need to have sufficient integration into Jetbrains IDEs (at a minimum). The first big problem--and it still is a problem--is the dependency management, in that there wasn't a solution to this out of the gate (unlike, say, Rust and Crate). Like I was shocked the first time I saw import 'github.com/some_random_user/...' 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'm not sure). It's kind of a mess. The second is, oddly, on concurrency or rather multi-core and multi-CPU utilization. Aren't we still in the GOMAXPROCS environment variable era? Really? EDIT: adding this quote from Rob Pike in 2012 [1] as it's a first-hand account of Go's original design goals: > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" 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++. [1]: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...