Rust Memory Management: Ownership vs. Reference Counting
1–10 of 54 posts
Re: Rust Memory Management: Ownership vs. Reference Counting
#2Solid intro. One pattern worth adding: when you're reaching for Rc> for graph-like or self-referential data, an index-based arena (Vec with usize "pointers") is often a third path that keeps you in plain-ownership land — at the cost of pointer identity and some bookkeeping. petgraph, slotmap, and most ECS libraries formalize this. Doesn't replace Arc for genuinely cross-thread shared lifetimes, but it eliminates a lot of cases where people first reach for it.
Re: Rust Memory Management: Ownership vs. Reference Counting
#3[flagged]
Re: Rust Memory Management: Ownership vs. Reference Counting
#4[flagged]
Reference counting is a form of garbage collection.
Re: Rust Memory Management: Ownership vs. Reference Counting
#5Re: Rust Memory Management: Ownership vs. Reference Counting
#6[flagged]
I miss the clear distinction between exclusive access and shared access when I work in GC languages. Knowing clearly when you are allowed/expected to modify a value, and when you are expected to only read the value ends up being very useful and it has poisoned my brain when working in Python/JS/Go where some values are internally pointers and there's no standard to learn once for when a mutation is safe or if you should always make a copy
Re: Rust Memory Management: Ownership vs. Reference Counting
#7[flagged]
I miss the clear distinction between exclusive access and shared access when I work in GC languages. Knowing clearly when you are allowed/expected to modify a value, and when you are expected to only read the value ends up being very useful and it has poisoned my brain when working in Python/JS/Go where some values are internally pointers and there's no standard to learn once for when a mutation is safe or if you sho…
One way to deal with this in GC languages is to have a separate read-only view on a mutable object. The example that comes to mind, though it's a bit more complex than a view on a simple data structure is CancellationToken (read only) vs CancellationTokenSource (writable in the sense of having "cancel()" method) in C#. I'm not saying it's better than proper mutability support but it does work well enough sometimes.
Re: Rust Memory Management: Ownership vs. Reference Counting
#8Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are optional, many can see this as greater programmer freedom to decide what to use for their projects, with languages that are easier to use or read.
Re: Rust Memory Management: Ownership vs. Reference Counting
#9Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are optional, many can see this as greater programmer freedom to decide what to use for their projects, with languages that are easier to use or read.
[flagged]
Re: Rust Memory Management: Ownership vs. Reference Counting
#10Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing. As these offerings are optional, many can see this as greater programmer freedom to decide what to use for their projects, with languages that are easier to use or read.
> Rust is becoming less special in this area. Languages such as Dlang, Vlang, and Julia have added optional ownership and borrowing
Isn't the crux that Rust does those things without a garbage collector, that's the novel part? Someone correct me if I'm wrong (likely), but I think all those languages have garbage collectors, which Rust doesn't.