WUFFS
WUFFS
Posted Aug 16, 2024 12:42 UTC (Fri) by khim (subscriber, #9252)In reply to: WUFFS by paulj
Parent article: Standards for use of unsafe Rust in the kernel
> Is runtime reference counted GC better than tracing GC?
You would need to define what do you mean when you are saying “better” if you want to have a meaningful answer to that quesion. So far I know one example of task where tracing GC looks like a better fit: theorem provers. First of all you, usually, have no idea, in advance, if said theorem can even be proven or not (and that means that “spurious rejectings” can be tolerated which immediately makes situation slightly unusual) and you genuinely don't know which data is still useful and which one is garbage.
But over years I only saw that one example where tracing GC is clearly the superior solution. Most of the time tracing GC is not just useless, but it's actively harmful if you goal is the Hoare property.
> Isn't it the case that more Rust programmes that have to work with more complex data-models and/or deal with long-lived state end-up relying heavily on RC/ARC?Yes, but there's an interesting Rust-specific side to that story: Rust doesn't have fully automatic reference counting! Or, rather, Rust does half of it (it automatically decrements counter when object is no longer needed and deallocates it when counter reaches zero), but it doesn't do automatic increment for you. This works very nicely because Rust passes objects around by moving then, not by copying them, which means that you usually need to do an explicit counter increment (by explicitly calling clone and obtaining copy of you refcounter-pointer) only in places where you need shared ownership.
This, again, leaves breadcrumbs in your code that help you to understand where do you split ownership and, again, helps to achieve the Hoare property.
