The two languages are quite different. Go is billed as a "systems language", for whatever that means, but in practice occupies a space similar to Java. It's quite well-suited for server and applications programming, but various design choices mean that it's less well-suited for lower-level programming domains like operating system components or device drivers, performance-intensive video games, or hard-real-time embedded systems.
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.
They both billed themselves as "modern C" but Go failed to deliver on that so instead it's now light/modern/ Java. Rust hopes to succeed as a "modern C" where Go failed.
Superficially, they both have curly braces, they are both being supported by prominent internet companies, and due to some mixed messaging, the public perception is that they are both systems languages. So it's not surprising that these questions are being asked, but I do hope that the message will get through to folks that despite surface similarities they are actually quite different.
I like Go and feel quite productive when building web services with it. It works well, but I think the Golang team neglected many advances in Computer Science, particularly the ones coming from the functional world, and the result is a nice language which could have been great. Rust appears to be that great language.
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.
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)
Gc<T> is not actually a garbage collector. It's a refcount + cycle detection. It was intended to turn into a real GC, but instead, it's in the process of being removed entirely.
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.
I wouldn't be so quick to give up on GC support yet! "We have a plan!" But I don't think we'll have it in for Rust 1.0. And it's true that, even if we never do get it to work in a satisfactory way, the language works just fine without it.
I'm curious about the reasoning behind the removal and what it means to Rust. Do you have any links on that? I tried looking on both Github and Discourse but couldn't find any more info.
Historically, @T, which is now Gc<T>, was assumed to be the 'default' pointer type. Like, from a conventions standpoint. And it was used all over the place.
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.
So, so that mean that Gc will probably be phased out of the standard library. Now I come to think of it, since Rust knows the lifetime of most (all ?) the memory, would it be thinkable that the compiler also optimise memory mapping/fragmentation ? Or would that interfere with Dynamically Sized Types ? I feel I really out to dig deeper into Rust once it's a bit more stable.
