[Regarding Rust:] > I dont think programming with regions is easy and you would ...

stormbrew · on March 8, 2014

I actually think the moves Rust has made away from an expectation of GC as part of the language will only help its adoption down the road. There are about 8 billion languages occupying some facet of the C++ With Garbage Collector niche and we don't really need another one. We need a better C++, and it's not a better C++ if you can't use it without a garbage collector, it's just another Java/D/Go/so on and on and on.

sixbrx · on March 8, 2014

I agree it should be usable without a garbage collector, for sure.

But some types of algorithms which are allocation heavy (with dynamically sized parts) will just run much faster with a good collector, and are easier to write that way.

Also I've found that with regions, things get really complicated when structures contain borrows (and not every structure will logically own what it references), and then the structures become parameterized over the lifetimes, which multiply quickly.

For cases like that I'd rather start with a GC reference, and gradually remove GC references where time permits and profiling dictates.

I think Rust can really have the best of both worlds here.

BTW: I did manage to finish a fairly involved analysis program in Rust without using any GC, and I'm really very happy with the results. Being able to GC a few references would have made things easier though.

kibwen · on March 8, 2014

  > For cases like that I'd rather start with a GC 
  > reference, and gradually remove GC references where time 
  > permits and profiling dictates.

Long ago this was one of the original theses of Rust, that you'd favor GC'd objects at first and then we'd provide easy ways to transition your code to use linear lifetimes where profiling deemed necessary.

It took us a long time and boatloads of iteration to finally realize that this just wasn't feasible. The semantics of GC'd pointers and linear types are just too drastically different, especially with how they interact with mutability and inter-task communicability. We "officially" abandoned GC in the language itself last October, and we're still trying to wrest the last vestiges of its use out of the compiler itself. Ask pcwalton how much of his time has been spent doing exactly that in the past four months. Just yesterday one of our most tenacious community contributors proudly announced that an all-nighter had resulted in removing two more instances of GC'd pointers from the compiler, which required touching "only" a few thousand lines. It's a bad scene.

So yes, while Rust will still offer GC'd pointers in the standard library, we've long since learned not to encourage users to reach for them without great justification. You must understand that once you introduce garbage collection into your code, it will be very difficult to return from that path.

We've also, in practice, tended to point people toward RC'd pointers (with weak pointers to handle cycles) whenever anyone needs multiple references to the same piece of memory. Thanks to linear types, reference counting in Rust is actually surprisingly cheap (many instances where other languages would need to bump the refcount are simply achieved by moving the pointer in Rust, since we can statically guarantee that that's safe).

sixbrx · on March 8, 2014

Thanks for the backstory, I may have been a bit naive then about how easy it would be to convert.

Good to hear about RC efficiencies, I assumed they were basically shared_pointer, I haven't tried using them and will give them a look.