Rob Pike interview

I would entreat you to not be afraid of Golang. To be frank its adoption speaks to a desire to make software that does not require (or, often, benefit from "staff SWE" skills). Treat it as what it is, a jumped-up, terser, and in some ways gutted Java, and give it another go. It is designed, to a fault--and this is a little pejorative, I absolutely do not enjoy writing Golang because of it--to be not that hard.

"Guess and check" is a technique that I have also used in Go code, and it is fine.

A lot of the compiler errors really could be errors in pre-commit hooks (like, the one about unused variables), but the language designers made a trade-off to be Even More Opinionated (than, say, Rails) because they thought it was best from a pedagogical perspective.

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-exponenti...

> I had to do a lot of work to get the code to compile again.

That's fine, in most cases, writing python code, you find out that you fucked up when you run the script. Compiler errors catch whole classes of errors that you ordinarily wouldn't find unless you ran the code.

Rust has channels though, unless I misunderstand what you mean.