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.

One 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...

Nitpick: 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

Always inferred statically for box.

No, 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.

Ooops yeah forgot about 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.]

Yeah 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.

It's all true.

Someday, long from now, I'd like to do a crater run with eager drop and see if anything actually breaks.

CStrings and drop guards everywhere break

Sure, 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 :).

Hell,

> GC is technically optional in C++, because you can stick pretty much anything in a reference-counted pointer (shared_ptr<T>).

week_ptr<T> - keeps a pointer for a week.

I 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!

I am unironically into both of these ideas.

Since C++11, C++ has a standard API for GC integration.

Or use https://github.com/manishearth/rust-gc, https://github.com/fitzgen/rajan-bacon-cc

Or Spidermonkey's GC, correct? My point was more about RAII not being the only resource management strategy.

Yeah, 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)