4 ms·

I’d say that’s a faulty distinction, especially in a review of programming languages. Rust’s lack of a mark and sweep with GC pauses while still allowing refere

I’d say that’s a faulty distinction, especially in a review of programming languages. Rust’s lack of a mark and sweep with GC pauses while still allowing reference counting is a feature rather than a detractor, especially when half of the issues putting e.g. Java into production are GC tuning related. It’s a language criticism in the same category as marking down Java because of its object oriented nature. If you’re finding that as a fault of Java, you’ve entirely missed the idea of the language.

klodolph 6y ago
> Rust’s lack of a mark and sweep with GC pauses while still allowing reference counting is a feature rather than a detractor… 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.
- ironmagma 6y ago
  How is reference counting slower than say, mark-and-sweep? It's not about what's better, it's about avoiding footguns. Rust (like all languages) has the capability to build a mark-and-sweep collector if you need it, but the built-in heap deallocation (Box + ownership transfer) combined with Rc means you basically don't need it where you might have in other languages. You can't accidentally get a GC pause in Rust, which is a feature. That's not to say there's no benefits to using mark-and-sweep. > 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.
  - klodolph 6y ago
    > How is reference counting slower than say, mark-and-sweep? 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.
    - zozbot234 6y ago
      > can avoid writing to dead objects, can put any state needed for garbage collection in a contiguous space, and can run “all at once” 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.

klodolph 6y ago

> Rust’s lack of a mark and sweep with GC pauses while still allowing reference counting is a feature rather than a detractor… 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.

ironmagma 6y ago
How is reference counting slower than say, mark-and-sweep? It's not about what's better, it's about avoiding footguns. Rust (like all languages) has the capability to build a mark-and-sweep collector if you need it, but the built-in heap deallocation (Box + ownership transfer) combined with Rc means you basically don't need it where you might have in other languages. You can't accidentally get a GC pause in Rust, which is a feature. That's not to say there's no benefits to using mark-and-sweep. > 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.
- klodolph 6y ago
  > How is reference counting slower than say, mark-and-sweep? 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.
  - zozbot234 6y ago
    > can avoid writing to dead objects, can put any state needed for garbage collection in a contiguous space, and can run “all at once” 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.