3 ms·

> The GC in Rust does need work. But so does C++'s GC and nobody is saying "C++ is not fast" because of it. C++ doesn't have a garbage collector, so I'm not su

> The GC in Rust does need work. But so does C++'s GC and nobody is saying "C++ is not fast" because of it. C++ doesn't have a garbage collector, so I'm not sure what you are getting at here.

widdershins 13y ago
He may be referring to shared_ptr, which implements reference-counted garbage collection in the standard library.
- pcwalton 13y ago
  Both, really. Neither shared_ptr nor Boehm are perfect, but that hasn't stopped C++ from being fast in practice.
  - cscottnet 13y ago
    Boehm is far from "fast in practice".
kibwen 13y ago
Sure it does, here's one: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Rust has a GC in the same sense that C++ has one, which is to say that its GC can be provided by libraries rather than being baked-in to the language.
- cwzwarich 13y ago
  Rust has GC that is part of the standard runtime / library with special language syntax to go with it. C++ has no such thing.
  - axelf 13y ago
    The special language syntax is being removed. Its now just a library.
  - kibwen 13y ago
    I'm about to blow your mind here: Rust has never had a GC. Managed pointers were always backed by reference counting, and the cycle collector stopped working sometime in 2010 and was never brought back online. Note that I said "were backed by reference counting" (emphasis mine), because managed pointers no longer exist in the language (unless you turn on the backwards-compatibility flag for them, which is only being provided temporarily). So there's no longer even special syntax for a theoretical GC. Instead the plan is to greatly expand our support for custom pointer types in general, which will make all user-provided pointer types (implemented in whatever libraries our users come up with) first-class citizens. Our own stdlib will include several pointer types of this nature, including: `Rc` (reference counting), `Arc` (atomic (thread-safe) reference counting), `RWArc` (memory-safe Arc for mutable objects), and, yes, a `Gc` type. And while it's true that we may provide hooks into the runtime to allow the `Gc` type to be implemented more efficiently, any user library will be able to use these hooks to implement its own GC. There won't be any implementation in the language itself.
deleted 13y ago
[deleted]
tomp 13y ago
C++ has ways of dealing with memory and garbage (i.e. memory no longer in use), such as `malloc()` and `free()`, or reference counting, or destructors, and not all of these are as fast as you want them to be in every situation (e.g. see the numerous malloc implementations), so in performance-critical applications/operations, you have to be very mindful of memory use and optimize correctly (e.g. by using memory pools).

> The GC in Rust does need work. But so does C++'s GC and nobody is saying "C++ is not fast" because of it. C++ doesn't have a garbage collector, so I'm not sure what you are getting at here.

widdershins 13y ago

He may be referring to shared_ptr, which implements reference-counted garbage collection in the standard library.

pcwalton 13y ago
Both, really. Neither shared_ptr nor Boehm are perfect, but that hasn't stopped C++ from being fast in practice.
- cscottnet 13y ago
  Boehm is far from "fast in practice".

kibwen 13y ago

Sure it does, here's one: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Rust has a GC in the same sense that C++ has one, which is to say that its GC can be provided by libraries rather than being baked-in to the language.

cwzwarich 13y ago
Rust has GC that is part of the standard runtime / library with special language syntax to go with it. C++ has no such thing.
- axelf 13y ago
  The special language syntax is being removed. Its now just a library.
- kibwen 13y ago
  I'm about to blow your mind here: Rust has never had a GC. Managed pointers were always backed by reference counting, and the cycle collector stopped working sometime in 2010 and was never brought back online. Note that I said "were backed by reference counting" (emphasis mine), because managed pointers no longer exist in the language (unless you turn on the backwards-compatibility flag for them, which is only being provided temporarily). So there's no longer even special syntax for a theoretical GC. Instead the plan is to greatly expand our support for custom pointer types in general, which will make all user-provided pointer types (implemented in whatever libraries our users come up with) first-class citizens. Our own stdlib will include several pointer types of this nature, including: `Rc` (reference counting), `Arc` (atomic (thread-safe) reference counting), `RWArc` (memory-safe Arc for mutable objects), and, yes, a `Gc` type. And while it's true that we may provide hooks into the runtime to allow the `Gc` type to be implemented more efficiently, any user library will be able to use these hooks to implement its own GC. There won't be any implementation in the language itself.

deleted 13y ago

[deleted]

tomp 13y ago

C++ has ways of dealing with memory and garbage (i.e. memory no longer in use), such as `malloc()` and `free()`, or reference counting, or destructors, and not all of these are as fast as you want them to be in every situation (e.g. see the numerous malloc implementations), so in performance-critical applications/operations, you have to be very mindful of memory use and optimize correctly (e.g. by using memory pools).