Reference counting is a GC though ?
It’s a bad one sure and will leak memory in cases of a cycle which most tracing GC are able to do.
It’s main advantage is that there are no GC pauses.
Comment on Which language you wish would really grow and reach mainstream adoption?
zygo_histo_morpheus@programming.dev 7 months agoYou are absolutely correct that rusts safety features don’t extend to memory leaks, but it’s still better than most garbage collected languages unless you abuse Rc or something, and it does give you quite fine-grained controll over lifetimes, copying and allocations on the heap which in practice means that rust is fairly good about memory leakages compared to most languages.
Akisamb@programming.dev 7 months ago
zygo_histo_morpheus@programming.dev 7 months ago
I think you know what I mean when I contrast Rust with GC’d languages, we can call it opt-in garbage collection if we’re being pedantic.
IAm_A_Complete_Idiot@sh.itjust.works 7 months ago
How would rust fare any better then a tracing GC? Realistically I’d expect them to use more memory, and also have worse determinism in memory management - but I fail to really see a case where rust would prevent it and GC languages wouldn’t.
zygo_histo_morpheus@programming.dev 7 months ago
If you just Rc everything (which I’d count as “abusing Rc”) Rust is significantly worse than a language with a good GC. The good thing about Rust is that it forces you to aknowledge and consider the lifetimes of objects. By default things are allocated on the stack, but if you make something global or dynamically handled (e.g. through Rc) you have to do so explicitly. In Rust the compiler has greater compile time information about when things can be freed which means that you need less runtime overhead to check things and if you want to minimize the amount of potentially long-lived objects you can more easily see how long objects might live by reading the code as well as get help by the compiler to determine if a lifetime-based refactoring is sound or not.