> garbage collectors for Rust that function reasonably are still pretty experimental
You can also use something like https://github.com/artichoke/cactusref - which provides an equivalent of Rc<T> with nearly-seamless, timely detection and collection of deallocation cycles. This gives you the equivalent of full GC, but using a "zero-overhead" approach that integrates more cleanly with how Rust idiomatically works.
Does it prevent stack overflows and stop-the-world delays in complex data structures?
Two common problems in most reference counting implementations.
Re:GC Fun at Twitch
by jashmatthews on Saturday November 16, 2019 @07:47AM
(#21552401)
IIUC Rust stack overflows are actually checked, hit a guard page, and unwind the stack https://github.com/rust-lang/compiler-builtins/blob/master/s...
A cactusref is owned by a single thread so there's no STW issue, but you also can't share them mutably between threads like structures available in some GCed languages.
Haskell and Idris and the like (other languages with a type system in the calculus of constructions) inarguably support a higher level of abstraction than Rust does, and are also “GC-obligate” languages. So your example is something of a red herring. I could say the same about Kotlin and Swift and Scala, none of which really have a strong story for static memory safety like Rust has, though it’s being considered for Swift. The only language that is reasonably complete that I could think to compare it to is ATS, which is far more complex as a result.