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.

Which is a performance bottleneck, as the compiler is blind to library implementations and cannot optimise accordingly.

Also implementation has nothing to do with CS definition, there are tracing GC libraries for C as well.

I agree with your first point, and I didn't say anything contrary to your second.

My point is about crossing the misunderstanding between the "two camps".

Fair enough.

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

Knowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.