4 ms·
Nitpick: GC is technically optional in Rust, because you can stick pretty much anything in a reference-counted box or an atomically-reference-counted box (Rc<T>
by anp 11y ago
Nitpick: GC is technically optional in Rust, because you can stick pretty much anything in a reference-counted box or an atomically-reference-counted box (Rc<T> or Arc<T>). It's not the default by any means though.
- vvanders 11y agoSure, much like C/C++ could have GC by embedding Lua, Spidermonkey, etc(fun fact Epic implemented their own C++ based GC for Unreal3). It's not a forced requirement :).
- masklinn 11y agoHell, > GC is technically optional in C++, because you can stick pretty much anything in a reference-counted pointer (shared_ptr<T>).
- malkia 11y agoweek_ptr<T> - keeps a pointer for a week.
- Gankro 11y agoI really wish calendar-oriented programming had taken better hold in the 80's. It's a really elegant paradigm with great separation of concerns. Being able to shard data out into timezones with inter-timezone accesses requiring a delay equal to their clock differences completely eliminates races! Unfortunately it was pushed out by MIT's cartography-oriented zealots, and we know how well that paradigm worked out!
- tatterdemalion 10y agoI am unironically into both of these ideas.
- pjmlp 10y agoSince C++11, C++ has a standard API for GC integration.
- yarrel 11y agoOne day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.” Moon patiently told the student the following story: “One day a student came to Moon and said: ‘I understand how to make a better garbage collector...
- mlvljr 11y ago+1 to anyone who knows the book name :)
- kzrdude 11y agoNitpick: Rust includes a GC. Box<T> is reference counted, although the reference count is always 1 until it is released by the owner, then it reaches 0. The reference counts are inferred statically for the most part. :-P
- Ericson2314 11y agoAlways inferred statically for box.
- Gankro 11y agoNo, if you conditionally move a box, there needs to be runtime checks for whether that condition occured when in it goes out of scope. (note that reassignment of a variable effectively causes the old value to go out of scope -- this may have Implications for your loops, though I sure hope you aren't making and destroying boxes in a loop!) In my experience, this is not however a significant concern.
- Ericson2314 11y agoOoops yeah forgot about https://github.com/rust-lang/rfcs/blob/master/text/0320-nonzeroing-dynamic-drop.md https://github.com/rust-lang/rfcs/blob/master/text/0320-nonz.... [To be perfectly pendantic, one could trade the drop flags for code bloat and have only a finite blow up and statically known everywhere, so its a "weak" form of dynamism.]
- Gankro 11y agoYeah I guess you could have exponentially many statically compiled paths for each combination of drop flags... but then you're just encoding your drop flags in the instruction pointer :) edit: this of course implies an easy program with 65 conditionally moved boxes that can't be encoded under your system.
- Ericson2314 11y ago
- Manishearth 11y agoOr use https://github.com/manishearth/rust-gc https://github.com/manishearth/rust-gc, https://github.com/fitzgen/rajan-bacon-cc https://github.com/fitzgen/rajan-bacon-cc
- dikaiosune 11y agoOr Spidermonkey's GC, correct? My point was more about RAII not being the only resource management strategy.
- Manishearth 10y agoYeah, Servo uses SM's GC for its javascripty things, it sort of has to. Hooking into spidermonkey to get a GC for a program where you just want a GC and not Javascript is suboptimal though. (Note that all of these GCs use RAII under the hood, but not in the simple delete-when-destructor way)