Rc and Arc aren't exactly GC types... they are just reference-counted pointers, Rc being akin to C++'s shared_ptr. I get that in a sense, this is garbage collection, but certainly not full-featured like the ones you find in other languages.

You can use full GC in Rust--we use the SpiderMonkey GC to collect Rust DOM objects, for example. It's not the most easy-to-use thing, however.

Most systems software gets by fine with a combination of thread-safe and thread-local RC. Reference counting is a form of garbage collection that works really well when it's used only for the subset of data that needs GC--which is the style that Rust encourages anyhow.

Hmm.. Rust was created to support the new browser, browsers mainly manage DOM objects.. I wonder why you are using a legacy garbage collector in order to handle primary tasks rather than having that part of your core design?

SpiderMonkey's GC is very modern, it's not legacy at all. Furthermore, while Servo influences the design of Rust, it does not dictate the design of Rust (or else, for example, Rust would have had struct inheritance years ago).

Spidermonkey uses generational gc with some kind of compacting these days. Why do you think that's legacy? What models are strictly better than that?

Nim's garbage collector is better than Spidermonkey's.

Irrelevant here.

For Servo we need a javascript engine. We're already using Spidermonkey. It has a GC for Javascript; we're already paying those costs. The Rust-side representation of DOM objects is also managed by the GC; that makes sense because these are tied to Javascript things.

We don't use the GC elsewhere. I think at some point we did, but the only place now in Servo where GC is used is where the data is strongly connected to data already managed by the SM GC.

Nim's GC is for general-purpose use in a language. Spidermonkey's GC is for GCing javascript, which already has an extensive runtime (which the GC ties into heavily). "Nim's GC is better than Spidermonkey's" is a statement of no value (and oversimplifies the situation) unless the context is specified. Using the SM GC to collect random Rust objects would be a bad idea. Somehow rigging up spidermonkey to use a Nim-like GC in Rust (all other things being the same) would also be a bad idea. Two different scenarios, two different GCs.

No, it's not. Generational, incremental, precise GC generally outperforms non-generational, non-incremental, conservative deferred reference counting.

Because rewriting Spidermonkey is both tedious and doesn't benefit from Rust safety guarantees.

Refcounting and tracing are two different forms of GC, but you're right in the sense that most people mean tracing.

At the same time, we're putting a lot of thought into how to properly add an optional tracing GC. It's important that it doesn't impact the no-GC case, which is still, of course, primary.

I'm glad to know there is ongoing work on a tracing GC. Rust has many strengths aside from lifetimes and ownership (algebraic data types, sane generics, strong module support, very strong type system), so a few features to make it more usable for use in contexts where performance isn't as important as expressivity would be very nice to have.

IMO, "contexts where performance isn't as important" aren't very relevant to Rust (hence why I'm strongly against, for example, hardcoding a global GC into the language, or splitting the language into a GC'd and non-GC'd half). But I do understand why some people would like to use the same language for all these use cases, I suppose.

I don't think the primary use case for a GC in Rust would be "contexts where performance isn't as important" so much as another tool for lifetime management.

The current reference counted types don't just get used for convenience, they get used because they describe the actual life cycle of the data they contain. A tracing GC would be similar.

Actually, std::shared_ptr is more like Rusts Arc type, because std::shared_ptr is atomic, and Rusts Rc is not.

I have disagree. I know what you mean in practice - the GC is not the default and some types will always be different. But reference counting and types with destructors is a valid implementation of GC.

Gc is "just" an automatic memory management. Rust is not a garbage collected language, but it does have optional garbage collection available.

Nim's GC uses reference counting, so I'd say it's a least a fair comparison: http://nim-lang.org/docs/gc.html

Ok thanks. It was not the first decision then, just one of the early main design decisions. I edited the text to reflect that.

It was not an early main decision. Rust has been actively developed for a full decade now, GC was removed from stdlib 2 years ago.

The decision was only done at the point when the devs were confident that the ownership/borrowing system could manage all the normal workloads done by GC, and that GC could now be implemented well into the language as a library.