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.
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)