9 ms·

I like it! It sounds like ~ pointers are basically like unique_ptr in C++11 or scoped_ptr at Google (http://google-styleguide.googlecode.com/svn/trunk/cppguide

I like it! It sounds like ~ pointers are basically like unique_ptr in C++11 or scoped_ptr at Google (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...). In practice, I find that these are the most commonly useful semantics, and as Patrick mentions it is simple and predictable. I fully agree that the landscape of GC/refcounting solutions is diverse. If indeed there is a way to allow for different approaches without favoring one, I think that would definitely make Rust more widely useful and future-proof. One question: one distinguishing factor of GC (vs refcounting) is the need to "stop the world" during the mark phase. Would there be a way of doing this from the standard library, or would the GC scheme itself be implemented outside the language? Likewise with any barriers that might be required for mutations, scanning the stack, and other tricky parts of implementing GC?

eru 13y ago
> one distinguishing factor of GC (vs refcounting) is the need to "stop the world" during the mark phase. That's a distinguishing factor only in practice. In theory there are real time garbage collectors.
- bad_user 13y ago
  In practice there are also hybrids that try to delay long stop-the-world phases as much as possible, but still need to stop-the-world when compacting the heap, like JVM's CMS. And I was under the impression that there already are GC implementations that never go into stop-the-world phases, like Azul's Pauseless GC [1]. There's also the new G1 from JDK 7 that promises to make pauses fewer and more predictable than CMS, while avoiding many memory fragmentation issues that CMS has (how well that works out in practice, remains to be seen, as it's not fully matured at this point). Btw, I love how Rust is trying to solve memory management issues by reinventing the problem. That's what new languages should do, instead of reimplementing other languages poorly. [1] http://www.artima.com/lejava/articles/azul_pauseless_gc.html http://www.artima.com/lejava/articles/azul_pauseless_gc.html
  - eru 13y ago
    On top of that, malloc (and friends) don't make any useful worst-case runtime guarantees either.
    - hga 13y ago
      That's very important to remember if your heap has a messy enough history. The right language + a good GC can give you much better bounded worse case guarantees, with Azul's as the best I know of for an imperative language (the more functional, the easier it is to do a variety of things).
  - hga 13y ago
    Yes, there are ones like Azul's, and don't forget the copying GCs that have different characteristics than mark/sweep(/compact).
steveklabnik 13y ago
> It sounds like ~ pointers are basically like unique_ptr in C++11 or scoped_ptr at Google I am not mega familiar with all of the details of {unique,scoped}_ptr, but my current understanding of ~ is this: basically, the compiler inserts a malloc before and a free after something declared with ~ goes into and out of scope, and it's the only pointer allowed to that memory.
- dbaupp 13y ago
  > it's the only pointer allowed to that memory Not quite true with borrowing (i.e. & and &mut), which allows a temporary pointer to the memory to be created. Unlike C++ however, the compiler makes sure all borrows are safe via a fairly intricate borrow checker, that guarantees (among other things) that the borrowed pointers don't outlive the original object. (i.e. no dangling references.)
  - steveklabnik 13y ago
    Ah! Yes. That's what I get for posting at 3am, thank you. :)
kibwen 13y ago
> one distinguishing factor of GC (vs refcounting) is the need to "stop the world" during the mark phase I can't answer the rest of your question, but note that Rust doesn't allow shared memory between tasks. Therefore, in the worst case, any garbage collector would only need to "stop the task" to mark, while the remainder of the tasks proceed uninhibited.
- ben0x539 13y ago
  That's only really true for the current GC design. I don't know if there is anything stopping someone from sharing memory via unsafe pointers and trying to manage that with a custom GC.
  - kibwen 13y ago
    True, I don't know if anything's going to stop you, but in my uninformed opinion you'd probably be violating so many built-in assumptions that you'd have to perform invasive surgery on the runtime to get it to work. But I'm hardly an expert in this area.

eru 13y ago

> one distinguishing factor of GC (vs refcounting) is the need to "stop the world" during the mark phase. That's a distinguishing factor only in practice. In theory there are real time garbage collectors.

bad_user 13y ago
In practice there are also hybrids that try to delay long stop-the-world phases as much as possible, but still need to stop-the-world when compacting the heap, like JVM's CMS. And I was under the impression that there already are GC implementations that never go into stop-the-world phases, like Azul's Pauseless GC [1]. There's also the new G1 from JDK 7 that promises to make pauses fewer and more predictable than CMS, while avoiding many memory fragmentation issues that CMS has (how well that works out in practice, remains to be seen, as it's not fully matured at this point). Btw, I love how Rust is trying to solve memory management issues by reinventing the problem. That's what new languages should do, instead of reimplementing other languages poorly. [1] http://www.artima.com/lejava/articles/azul_pauseless_gc.html http://www.artima.com/lejava/articles/azul_pauseless_gc.html
- eru 13y ago
  On top of that, malloc (and friends) don't make any useful worst-case runtime guarantees either.
  - hga 13y ago
    That's very important to remember if your heap has a messy enough history. The right language + a good GC can give you much better bounded worse case guarantees, with Azul's as the best I know of for an imperative language (the more functional, the easier it is to do a variety of things).
- hga 13y ago
  Yes, there are ones like Azul's, and don't forget the copying GCs that have different characteristics than mark/sweep(/compact).

steveklabnik 13y ago

> It sounds like ~ pointers are basically like unique_ptr in C++11 or scoped_ptr at Google I am not mega familiar with all of the details of {unique,scoped}_ptr, but my current understanding of ~ is this: basically, the compiler inserts a malloc before and a free after something declared with ~ goes into and out of scope, and it's the only pointer allowed to that memory.

dbaupp 13y ago
> it's the only pointer allowed to that memory Not quite true with borrowing (i.e. & and &mut), which allows a temporary pointer to the memory to be created. Unlike C++ however, the compiler makes sure all borrows are safe via a fairly intricate borrow checker, that guarantees (among other things) that the borrowed pointers don't outlive the original object. (i.e. no dangling references.)
- steveklabnik 13y ago
  Ah! Yes. That's what I get for posting at 3am, thank you. :)

kibwen 13y ago

> one distinguishing factor of GC (vs refcounting) is the need to "stop the world" during the mark phase I can't answer the rest of your question, but note that Rust doesn't allow shared memory between tasks. Therefore, in the worst case, any garbage collector would only need to "stop the task" to mark, while the remainder of the tasks proceed uninhibited.

ben0x539 13y ago
That's only really true for the current GC design. I don't know if there is anything stopping someone from sharing memory via unsafe pointers and trying to manage that with a custom GC.
- kibwen 13y ago
  True, I don't know if anything's going to stop you, but in my uninformed opinion you'd probably be violating so many built-in assumptions that you'd have to perform invasive surgery on the runtime to get it to work. But I'm hardly an expert in this area.