Go and Rust offer GC. Rust allows you to choose when you use it. Rust also makes it explicit when you're allocating memory whatsoever.
Go and Rust offer M:N threading. Rust provides separate heaps per "task" and a data ownership system which means you never end up sharing state between "tasks" (ala Erlang). Go only provides a global shared heap. This means Rust can prevent a class of bugs (concurrent mutation of shared state) which Go can't. It also means Rust's GC is easier to run in parallel, since state is isolated to particular tasks so you can GC a task while it's idle ignorant of the rest of what's going on in the system.
Go and Rust both offer structural typing (like duck typing with static typechecking). Rust also implements Hindley-Milner, which is the same type inference algorithm used in Haskell. So Rust provides Go-like typing when you want it, and a "real" type system when you need it.
Rust is immutable by default. I think the benefits of immutable state go without saying, but Rust also lets you opt into mutable state if you want it.
Rust is memory-safe by default, meaning that mistakes made by programmers won't corrupt memory or cause the program to crash. However, Rust also offers an unsafe mode that provides C-like memory access, making Rust suitable for things like kernel development, bootloaders, microcontrollers, and other device firmware that still needs to do C-like things in order to function.
Rust can be used for "bare metal" low-level development, to the point that you can boot directly to Rust without ever starting its runtime, and even use Rust directly on microcontrollers. See "Rust on bare metal" (lolpun): https://mail.mozilla.org/pipermail/rust-dev/2013-July/004841...
Finally, Rust provides a task linking/fault-tolerance model similar to Erlang where if one task exits, tasks it's linked to are automatically notified about an exit event and can take action accordingly.
Rust is a weird platypus of a language with a lot of the features you see in fancy functional languages but working in more or less the same realm as C/C++. I've heard it described as "if C++, ML, and Erlang had a kid"