Let me preface this by saying I like Go. I do. But as much respect as I have for Rob Pike (which, again, I do), he doesn't understand the systems programming space. Go was originally pitched as a systems programming language, a better C, like you said.

But it isn't. It is, however, a better Python (IMHO).

The reason it's not a better C is that it's a garbage-collected language and it has a runtime overhead. As such, Go doesn't really have predcitable performance. It's easy to blow up memory usage (as it is on any GC language) eg goroutines.

So Go just doesn't suit a typical systems or embedded application. Yes, you can use a subset of Go to avoid dynamic allocation and GC in general but really, what's the point in that?

Why it's a better Python (again, IMHO) is that Python has all the same negatives but has a few more, most notably that it is dynamically typed or, as I like to put it, you need to write unit tests for spelling mistakes. I've come to abhor dynamic typing as a truly horrendous false economy. Go doesn't have that problem. Go does need to be compiled but it's a simple language and that compilation is incredibly fast.

My one criticism is that I find Go's unbuffed channels to be a less elegant coordination mechanism to cooperative async/await in other langauges. But YMMV.

Some evidence to back this up is that, at least while I was still at Google, Go projects on google3 were cannibzlizing Python projects and nothing else really.