leaving aside the first-mover advantages like community, docs, stdlibs, api stability, where do you see rust's advantages over go?
On the other hand, Rust is aimed at being a replacement for C++ or even C: it allows for precise control over lower-level aspects of the machine while providing more static guarantees of correctness by means of a powerful type system. For example, Rust prevents dangling and null pointers and disallows access to uninitialized memory while retaining manual memory management, as well as allowing garbage collection as a library-provided feature and not a core language feature. In that sense, Rust is suitable for problem domains that Go is not.
When you see Rust it's clear that they have taken note of these advances and added them to the language. Pattern Matching, Algebraic Data Types, Hindley-Milner type inference accompanied by a sophisticated type system, everything is an expression (well, most), immutable variables by default and type classes are all things that many of us who were exposed to the functional world miss sorely in mainstream languages like Java. Rust includes all of them while Golang doesn't, and C++ doesn't have some of them.
And it doesn't end there, in Rust you can also do OOP, though it's different from Java (no classes, more similar to Go). You have concurrency primitives baked into the language as in Go. You have generics as in C++ (the most cited criticism of Go, which lacks them). It lets you manage memory but in a safer way than C. And it can be made compatible with C, which lets a library written in Rust be used by other languages.
So, Rust really feels like the superior replacement of C++, and possibly C, that Golang promised at first, and it has a chance of becoming mainstream when it's stable. Rust offers all the things that Golang does, and many more. The tooling is generally better in Go, but it surely can be improved.
Lack of garbage collector ? There is a garbage collector in the standard library : http://doc.rust-lang.org/std/gc/
It gives you even more control I would say as you can choose when/if to use a garbage collector. Which is not always a bad idea (See https://news.ycombinator.com/item?id=8263811)
I've gone through and cleaned up all the references to it in our docs and marketing, so we stop misleading people with this notion.
As we wrote more and more Rust, it became clear that unique ownership (~T, now Box<T>) was just as useful, faster, and better. Remember, this type basically compiles down to a regular pointer, with compiler inserted malloc/free. So you can imagine how much less that is compared to a refcount + cycle detection.
So, Gc<T> was never really improved, and it's usage in the compiler itself was less and less. The last place it was used was in the AST, and so syntax extensions used it, but we didn't recommend it for anything else.
Now, this past week, a contributor managed to re-write the AST to not use Gc<T>, so even than is gone. Or will be soon, I forget if it's passed CI so far. But anyway, now that it's gone, it will probably be simply removed, though that decision hasn't been made yet.
Basically, what it means is that affine types are awesome.