I might be wrong, but I think you took offence to me suggesting you might be confused. If so, I'm sorry. I didn't mean it in a negative way, I was trying to soften my language but I phrased it badly.
Regardless, my point was that Rust _the language_ does not provide garbage collection. The Arc/Rc structs are where the reference counting is implemented. You can create reference counted objects in C, like GObjects in GLib. However, I think you would agree with most people that C does not have garbage collection. Otherwise the concept of a language having or not having garbage collection is diluted to the point of meaninglessness. At that point I think memory management is a more apt term.
> Regardless, my point was that Rust _the language_ does not provide garbage collection.
These are language features not dependencies or external libraries. Maybe the best phrasing is that Rust's garbage collection features are opt-in, similar to the same features being opt-out for Go, Nim, OCaml, and others.
GLib is an external library to C and C's standard library. Arc/Rc (and there are other types of garbage collection within Rust _the language_) are language features since they are built-in types.
The delineation is very clear here. If it is part of the language's standard features and/or standard library then it is part of the language. Using opt-in/opt-out terminology also make clear how the garbage collection features are available. In Rust, you opt into garbage collection by using specific built-in types.
Regardless, my point was that Rust _the language_ does not provide garbage collection. The Arc/Rc structs are where the reference counting is implemented. You can create reference counted objects in C, like GObjects in GLib. However, I think you would agree with most people that C does not have garbage collection. Otherwise the concept of a language having or not having garbage collection is diluted to the point of meaninglessness. At that point I think memory management is a more apt term.