> scripting languages
That's what they say, but in practice people report that the lack of the more intuitive tooling like REPL in Python is a common reason not to use Go for scripts.
> not really with either C or C++
Well in terms of e.g. concurrency, compiling, syntax... the initial intent by Pike and Thompson was clearly unambiguously to do better than C++, which was the language they used at Google at the time.
They literally dug up SCP (1978) and the Oberon family to design a simpler, more manageable approach (the Go spec really is user-centric from inception). It was also months after the release of the first multicore CPU by Intel (Core2Duo iirc?) which paved the way to parallelism.
Regarding C, I agree in terms of domain / purpose insofar as C goes below (not familiar with it myself but cgo lets you inject C). I suppose I mentioned C because that's the standard performance benchmark that people tend to aim for (including the Go team, often), and Go is often a very valid albeit much simpler direct alternative to writing some package in C.
About Rust, thanks a lot for the precisions. I'm not as familiar with it as Go. I do find that Rust has incredible potential to be a really good high-level language, much more expressive than Go will ever be (by design, different goals).