Re:For Better Computing, Liberate CPUs from Garbage Collection
by tomp on Thursday May 09, 2019 @11:43AM
(#19869260)
Weakrefs require “careful programming” i.e. knowing which ref must be a weakref.
By “cheating” I don’t mean “unsafe” but all kinds of pointers that aren’t just unique or borrowed such as different reference-counted pointers, the existence and use of which demonstrates that ownership+borrowing isn’t a complete memory-management technique. You need reference counting, therefore you need GC or careful programming.
Hopefully we discover some technology that makes these needs go away, but not so far AFAIK.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by m0th87 on Thursday May 09, 2019 @10:06AM
(#19868383)
The point with weakrefs, though, is that they still require developer intervention.
Also, you can use most memory management facilities in Rust (including reference counting) without `unsafe`.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by arcticbull on Thursday May 09, 2019 @01:43PM
(#19870398)
Correct, leaks are considered "safe" -- it's premature deallocations that are considered unsafe.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by apta on Thursday May 09, 2019 @10:04AM
(#19868375)
I think the poster to whom you're responding means things like Cell and/or RefCell, which allow mutation behind the scenes while still being safe.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by cyphar on Thursday May 09, 2019 @10:20AM
(#19868512)
Right, but I think their main complaint is that RefCell is implemented using "unsafe" -- hence my point about "unsafe".
Re:For Better Computing, Liberate CPUs from Garbage Collection
by apta on Thursday May 09, 2019 @04:34PM
(#19872147)
It's API is not `unsafe` though. Otherwise, every safe API depends on some `unsafe` call down the call graph.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by cyphar on Thursday May 09, 2019 @06:59PM
(#19873309)
I think we're both in agreement, I was phrasing things in a manner which I thought would better reference how GP thinks of unsafe. Obviously the API itself is safe, but the "cheating" GP was referring to was the fact that Rust requires "unsafe" under the hood in order to implement some safe operations (because the memory model doesn't cover all cases). You and I agree that this isn't a problem.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by wbl on Thursday May 09, 2019 @11:20AM
(#19869061)
Reference counting is a garbage collection algorithm. It just isn't a very good one compared to semi space because its runtime is the number of dead objects not live objects.
Re:For Better Computing, Liberate CPUs from Garbage Collection
by cyphar on Thursday May 09, 2019 @09:54PM
(#19874381)
Refefence counting is barely classifiable as garbage collection. The runtime is O(1) because you free the object immediately when it dies, there's no stage where you start looping over dead objects.
This is what weakrefs (or better data structures) are for. The Linux kernel uses reference counting incredibly effectively for almost every structure. I think that pretty much discounts any argument that reference counting cannot work.
> (5) Rust features a lot of "cheating" - pointers that allow mutation from multiple threads, reference-counted pointers, etc. - so obviously just ownership&borrowing isn't good enough
"unsafe" isn't cheating and isn't even related to whether garbage collection is a good idea or not. Yes, Rust's ownership and borrowing model doesn't cover all programs and hence "unsafe" is required -- but "unsafe" doesn't use a garbage collector so the existence of "unsafe" doesn't change that Rust works without one.