How does Rust reference counting handle cycles? Python is famously reference counted, and even it ended up having to strap on an occasional GC cycle to mop up after those. Or do you just accept that if it leaks, it leaks? Which for most finite-lived programs on generous modern hardware may be a sufficiently acceptable solution.

...

Still, I do idly† wonder if there could be better schemes[sic] than just slavishly refcounting everything? e.g. If you know which values never escape a given scope, maybe just dump them into a single-ownership pool that’s collected whenever execution finally leaves that scope. Which, for lists that compose the program itself, is the entire lifetime of the program (so no need to explicitly collect assuming the OS is happy to clean up after the program exits). It’s really just values that leave their originating scope that need to start refcounting (although, of course, there’s a raft of ways they can sneak out of that).

Although I think the most inventive answer to dynamic memory management was the language that simply tossed all newly created values into a single global cache, from which it periodically swept all values that weren’t touched again within a fixed period of time. (Obviously requiring 100% referential transparency, so that if an already-flushed value is needed again, it can simply be regenerated from scratch.) Alas, I can’t remember that language’s name (I think it’s an older and obscure one), but simple, effective, and sneaky AF? #MeLikes

--

† Alas, while I have considered implementing a scripting language in Rust (to teach myself Rust as much as anything else), I’m already painfully slow writing them in HLLs that do all that low-level stuff for me. #BoVLB :/