Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.
Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.
Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".
My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.