5 ms·
Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor hel
by drewm1980 6y ago
Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor help from the programmer. This may make your code faster or more likely to be correct than code written in some of those languages.
- laurencerowe 6y agoThat's a fair point, I should distinguish heap allocation from reference counting. It still seems somewhat tricky to replicate the well proven arena allocation approach of Apache and Nginx which avoids memory fragmentation in current stable Rust though.
- kd5bjo 6y agoFor general areana allocation, you can use something like the Bumpalo crate: https://docs.rs/bumpalo/3.4.0/bumpalo/ https://docs.rs/bumpalo/3.4.0/bumpalo/
- blub 6y agoIt didn't figure them out at all, the programmer had to figure them out the hard way and then code them in so that the compiler understands them. GC is figuring out things mostly correctly and the programmer can focus on other things, at least until they hit a performance problem :)
- Lorkki 6y agoFor the most part, lifetime is inferred from scope, so there isn't anything special to figure out; objects live exactly for as long as you can see and use them. This also includes such things as lock handles, or references to refcounted objects.
- jashmatthews 6y agoOnly in the most trivial cases. Tons of real Rust uses copying or RC/ARC or even unsafe to avoid dealing with complex lifetimes because it's... complex.
- Lorkki 6y agoCopying, refcounting and locking work within the exact same semantics. They're among the most typical tools that are used to transmit or share data, so I'm not sure why it should be strange to see them used in most real programs?
- Karrot_Kream 6y agoThat doesn't change the reality of allocation though. Programmers in languages like C++ and Rust choose when and where to allocate memory, and if there's one thing we know about performant code, it's that we shouldn't be allocating and deallocating repeatedly. Nothing about lifetimes helps or hurts about this programming model. Lifetimes (Rust) and RAII (C++) are just semantic models to help reign in the cognitive load of memory allocation.
- adrianN 6y agoI doubt that you'll write a large Rust program without relying on refcounting at least for some of your objects. Refcounting is not fundamentally different than a GC.
- zozbot234 6y agoReference counting is a kind of garbage collection (taken broadly), but it's quite different from tracing GC.
- jashmatthews 6y agoNaive use of RC doesn't look like tracing much but as soon as you need cycle-aware RC like the CactusRef the algo looks a lot like tracing GC https://github.com/artichoke/cactusref#cycle-detection https://github.com/artichoke/cactusref#cycle-detection
- rcxdude 6y agoI don't think you've understood the nature of the borrow checker in Rust. It doesn't add any extra runtime behaviour, in fact you could compile Rust code without running these checks (though I don't think rustc provides you with a way to do so). Rust's memory management tools are no different from C++: you have stack allocated structures with destructors, which the standard library uses to implement heap-allocated smart pointers, shared pointers, mutex guards, etc, and you can hand out pointers to any of these. The only difference in rust is it checks how these pointers get handed out so you don't get use-after-free, data races, etc.