Ridiculous. `Rc` exists for one purpose: reference counted data. When all the references are gone, it will be freed. That’s garbage collection by definition.
I already knew this article had dubious judgment when they knocked C++, the daily driver for performance-obsessed game developers, down because of lack of concurrency support though.
My favorite error is also rust related :
> Rust has no built-in support for immutable data structures.
This piece is flamebait.
It depends on your definition of garbage collection though, doesn’t it? People often make a distinction between reference counting and garbage collection. Even though you can use reference counting in a GC'ed system (example: CPython), in most conversations people talk about reference counting as something different from garbage collection—for example, Objective-C’s ARC is seen as a different memory management technique from GC (you can have one or the other).
I think most people would not describe Rc or std::shared_pointer to be garbage collection.
Gonna stop you right there, because you’re arguing about which type of memory management is BETTER. That conversation is not one that’s going to come to a conclusion on this website because outside of certain scenarios where you might be forced to choose reference counting or garbage collection, in general, it’s just a tradeoff.
Reference counting is generally slower and less accurate, garbage collection uses more memory and has poorer latency guarantees. ¯\_(ツ)_/¯
> If you’re finding that as a fault of Java, you’ve entirely missed the idea of the language.
I don’t understand what you mean by that. Java is a product of the 90s and “everything is a class, classes encapsulate mutable state, subtype polymorphism” fell out of that. It was a bit of a fad, and the fad got baked into the language.
> It was a bit of a fad, and the fad got baked into the language
That may be its origin story, but if you look at Java among its current contemporaries, the story is, "What would happen if we had a language where literally everything had to use object-oriented programming, including Hello World? How would it turn out?" and the answer is very popular and used in enterprises heavily. If you can't stand OOP, the notion of even entertaining Java as a viable language is a flawed premise.
That’s a good question! The answer is pretty interesting. It turns out that there are a number of factors. Speaking in generalities here: reference counting touches pages precisely when you are done using them (thwarting possibly multiple LRU caches), and the deallocation must run interleaved with the mutator, which is a classic slowdown. Garbage collection algorithms like mark/sweep or copying collectors can avoid writing to dead objects, can put any state needed for garbage collection in a contiguous space, and can run “all at once” so the deallocator is not constantly competing with the mutator for cache, etc.
And then there’s the fact that with reference counting you still have to increment / decrement the reference count, and even if you only incref / decref each object once, there are still faster garbage collectors out there (measured by throughput / amortized costs).
This is the explanation for the empirical observation that reference counting is generally not very fast, although there are cases where it works well.
To get back to the original point—the claim that “Rust does use garbage collection” should not be controversial. The fact that you could beat Rust into submission until a garbage collector comes out is not really a counterargument I care to entertain.
> Rust (like all languages) has the capability to build a mark-and-sweep collector if you need it, …
You would have to build a fairly primitive mark-and-sweep collector, or rely heavily on unsafe constructs. You wouldn’t be able to compete with, say, Go or Java, which insert instructions into the generated code to make concurrent garbage collection work (synchronization points).
You would probably be able to compete with implementations like CPython, which has stable pointers, reference counting, and uses mark-and-sweep to collect cycles.
> You can't accidentally get a GC pause in Rust, which is a feature.
It comes with tradeoffs. For example, Rust lets you leak memory, and allocation is slower than in GCed languages.
> …and the answer is very popular and used in enterprises heavily.
That’s selling Java short. There are a lot of reasons why Java is popular, and explaining it in terms of OOP really doesn’t do it justice.
You can use arena allocation when these issues are relevant (which is not that often). Generally speakingm while obligate RC (particularly ARC) is indeed lower-throughput than obligate tracing GC, Rust does not really use obligate RC.