They are two entirely different use cases. Rust is for replacing C/C++ with a safer alternative. Go is basically for developers that never fell in love with Java or C# but need the same kind of language.
Do those usage distinctions really hold? We all know the mythology that Go was created as a replacement for C++ (the Go FAQ still lists it as being created because of the poor system language tools). Rust targets largely the same problem space. They're both compiled languages that in an idealized world could offer C levels of speed.
Go also offers a lot of high level constructs that allow you to create a web server and other solutions traditionally built in higher level platforms, but that doesn't reduce its low level functionality.
Rust can call and be called by C code without a translation layer. To me, this is a requirement for any language that is truly going to replace them. Also, Go went down the GC path which limits its applications to those where you can have unpredictable pauses and for me firmly places it in the Java/C# part of the spectrum.
I'm not attempting to advocate Go here (they're both fantastic options), but any application running on a non real-time OS can have unpredictable pauses. That's the world of preemptive multitasking. Of course this is a scale thing (Go doesn't escape those OS pauses), but Go 1.8's own pauses are in the sub-millisecond range.
C# and Java have pauses in the hundreds of millisecond range (though there are "real-time" JVMs that greatly improve this). And it's notable that Go goes to lengths to avoid generating garbage.
Go has a non-compacting GC (hugely important for integration with other native code, where I should also mention it has C-style struct layouts), and in recent iterations has pauses in the microseconds range. And that's if you're actually creating garbage, as the escape analysis (which happens at compile time, given that Go is not a VM-targeting platform) makes it extremely easy to avoid garbage at all.
Rust has escape analysis and reference counting. It really isn't so different.
Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time and any failures are flagged, meaning one has a stronger idea of the actual runtime behaviour of the code. Additionally, reference counting is used far less than GC pointers in languages like Go, even accounting for their escape analysis.
In terms of integration with native code, the concurrency model of Go means calling native functions has high overhead because it has to switch to a native stack (thi iss one possible motivation for why Go does syscalls directly on Linux: avoid the stack switching overhead).
Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time
Go makes the stack/heap decision at compile time as well. It is far closer to C++ than Java. To your other point, cgo calls indeed have a high overhead in an absolute sense, and ideally you do fatter, more meaningful calls.
I am not advocating for Go, it just seems that these discussions often pigeonhole technologies, and a common one is the strange belief that Go is just another Java/C#, and Rust is the next low level language.
I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's still perfectly happy to implicitly promote things to the heap to make code work. This means that Go offers less control over memory (one of the things needed in a low-level language) than Rust. When, for instance, variables are being passed between threads/goroutine-equivalents, Rust will notice that things are trying to escape and tell the programmer that they need to decide how they want to handle it, rather than make the decision implicitly. (The Go approach isn't like C++ either, which also doesn't implicitly allocate, like Rust.)
There are many other aspects in which Go does not offer as much control as Rust, e.g. the former incorporates a runtime and garbage collector. This isn't disagreeing that Go offers more control than Java, but Rust (and C++) offers even more than Go.
How do you think that refutes what I said? Go absolutely makes that decision at compile time (of course it does -- Go does not have a VM). Is your point that they say that you shouldn't sweat it? Because of course you shouldn't, and ideally it is making the right choice, which most of the time is the stack.
