6 ms·

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 collec

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.

steveklabnik 11y ago
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.
- filsmick 11y ago
  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.
  - Jweb_Guru 11y ago
    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.
  - Rusky 11y ago
    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.
pcwalton 11y ago
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.
- ilaksh 11y ago
  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?
  - viraptor 11y 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?
    - ilaksh 11y ago
      Nim's garbage collector is better than Spidermonkey's.
      - Manishearth 11y ago
        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.
viraptor 11y ago
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.
sinistersnare 11y ago
Actually, std::shared_ptr is more like Rusts Arc type, because std::shared_ptr is atomic, and Rusts Rc is not.
wtetzner 11y ago
Nim's GC uses reference counting, so I'd say it's a least a fair comparison: http://nim-lang.org/docs/gc.html http://nim-lang.org/docs/gc.html

steveklabnik 11y ago

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.

filsmick 11y ago
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.
- Jweb_Guru 11y ago
  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.
- Rusky 11y ago
  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.

pcwalton 11y ago

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.

ilaksh 11y ago
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?
- viraptor 11y 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?
  - ilaksh 11y ago
    Nim's garbage collector is better than Spidermonkey's.
    - Manishearth 11y ago
      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.

viraptor 11y ago

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.

sinistersnare 11y ago

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

wtetzner 11y ago

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