Trying to evaluate to what extend hard real-time programming is possible in Rust, I stumbled upon Stackoverflow questions from 10 years ago here and here. These mention "garbage collection" and an @-operator for pointers that has something to do with "managed pointers".
This confused me a litte in the beginning until I realized that the questions were that old, but now I am interested in the historical remarks. At some point, was there a garbage collection planned to be built into Rust?
I'm unfamiliar with the details, but yes, pre-1.0 Rust had a garbage collector.
Wow, didn't know Rust had an @ operator. Seems it does and it is nothing to with pointers. Pattern Syntax - The Rust Programming Language
@ does "pattern binding", whatever that is. The example in the book Pattern Syntax - The Rust Programming Language is so ugly and inscrutable I don't really grasp what it does. Hope I never have need to write such a thing.
Luckily Rust decided against garbage collection and that is one of the main reasons we are all here.
"@" does "pattern binding", whatever that is. The example in the book Pattern Syntax - The Rust Programming Language is so ugly and inscrutable I don't really grasp what it does. Hope I never have need to write such a thing.
It's not that obscure, though I guess not that common either. The reference has some more motivating examples. It's particularly useful for binding slice rest (..) patterns.
RFC 256 may be of interest. It was written after the @x syntax was removed, but before the type behind it was. Before it went away, @x meant Gc::new(x), and Gc was like Rc but with extra language magic. But it was never a full garbage collector! It was reference counting, and got removed before the garbage collector ever happened.
The intention was that Rust would provide a task-local garbage collector as part of the standard runtime for Rust programs.
As a short-term convenience, @T and @mut T were implemented via reference-counting: each instance of @T/@mut T had a reference count added to it (as well as other meta-data that were again for implementation convenience).
So, if you find ancient Rust code that uses @T, you should read it as roughly Rc<T>, in the same way that ~T should be read as Box<T>.
My understanding is that @T/Gc<T> was allocated on a task local heap, which got deallocated when the task (green thread) exits, thus deallocating everything that didn't get deallocated before due to cycles.
I'm not familiar with that part, but yes, I was oversimplifying. Still: that's a combination of reference counting and an arena; it's still incapable of collecting cycles while the task is running.
So, I think it's more accurate to say that Rust never had a garbage collector but at one point had ambitions to include one, rather than that it used to have one.
(pushing glasses up nose) I believe you mean a tracing garbage collector. 
Wow, didn't expect to spark such a thorough discussion. Thanks for all the input!
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.