I don't know Go, so I cannot make a comparison, but studying Rust has been very useful to me as someone interested in the principles of programming because it forces you to think deeply about pointers.
In C, pointers are used for many different things: they stand for arrays and strings (which IMHO is a questionable choice); they are used in types where the structure of an object changes at runtime (linked lists, trees); they provide a way for different parts of the program to refer to a common state; they allow subroutines to modify objects 'owned' by calling routines; they provide a cheap way to pass big structures as arguments to subroutines even when they won't be modified; they provide a way of incorporating large structures as elements of other structures which allows replacing one value with another without a full copy.
Some troubles with pointers are specific to the ways that C uses them: manual memory allocation means that you can use before alloc or after free; the NULL value means that you can dereference an invalid pointer; pointer arithmetic means that a valid pointer can be used to produce an invalid pointer. At possibly some small runtime cost we can eliminate these problems.
But there is one unavoidable problem at the heart of the use of pointers. When you are referring to something with a pointer, are you doing it just for convenience, to avoid copying large structures; or are you doing it to share state with other parts of the program? Things will go horribly wrong if you end up doing the latter when you just wanted the former.
Rust's type system is an attempt to keep track of different uses of pointers to catch such errors without compromising on efficiency. There have been other attempts ([1],[2]) but Rust finally has a rich enough language and library to attempt writing serious programs in.
I think it will be interesting to see whether the authors of such programs find the mental effort of keeping the borrow checker happy worth the efficiency gains of using pointers for both purposes on an equal footing, or whether they fall back to the extreme models of Python (and many other languages) where everything is a pointer which shares state or that of Haskell where there are no pointers by default and one has to switch to a explicit and cumbersome syntax (using the IO or ST monads) when one wants to use shared mutable state.
[1] https://en.wikipedia.org/wiki/Substructural_type_system
[2] http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-l...