Sure, ARC is a form of very specific, constrained garbage collection.
Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.
Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime.
Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.
While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.
Sure, ARC is a form of very specific, constrained garbage collection.
Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.
Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime.
Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.
While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.
3 replies →
But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector.
Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic
1 reply →