Rust is quite a lot harder than Go. While lots of practice makes it easier, it's still not trivial to reason about lifetimes/borrowing/moving, unlike a GC language (which isn't to say that GCs are strictly superior to other memory management schemes, mind you). There are lots of good reasons to choose Rust over Go (you have extreme performance or correctness requirements, for example), but "Rust is comparably easy to Go" is untrue (or as untrue as any user-friendliness assertions can be).
EDIT: I don't mean to convey that GCs are still trivial in a mixed-runtime context; only that Rust is generally harder than Go.
Except if you're embedding a runtime you invert the simplicity of a GC.
As soon as GC'd pointers start passing across an FFI boundary you either need to:
1. Pin them and track yourself, which then loses a lot of your advantage of having a GC since you've got non-deterministic seg-faults based on when GC runs and pulls objects out from underneath you. C# lets you do this, but it's really painful to get right.
2. Prevent any GC objects being passed(which is what Go does). This means that there's a lot of things you can't do(esp with respect to callbacks and future events) that require a ton of gymnastics to do something that's trivial in C.
EDIT: I don't mean to convey that GCs are still trivial in a mixed-runtime context; only that Rust is generally harder than Go.