Rust Memory Management: Ownership vs. Reference Counting • Hacker News Board

Re: Rust Memory Management: Ownership vs. Reference Counting

#51

Post by andriy_koval » Mon, Apr 27, 2026, 9:08 PM UTC

simonask wrote: post #49

BiteCode_dev wrote: post #47

Earlier quoted context omitted.

Do you have a simple example of how this is done correctly? I always heard that but comming from Python internal references would be the way to go so it's not natural to me.

Depending on the shape of the graph (arbitrarily connected, DAG, etc.), it just boils down to whatever convenient way you have of storing lists. Node data in one list. Indices of node parents in another list of the same length. If you need to find children quickly, you can have another list of lists containing children indices. The key is to consider the node’s position in the list as its ID, and refer to nodes by th…

All these Weak, RC are needed for allocation/deallocation of memory. Having data in list with indexes means you don't have this functionality.

Re: Rust Memory Management: Ownership vs. Reference Counting

#52

Post by BiteCode_dev » Tue, Apr 28, 2026, 8:20 AM UTC

simonask wrote: post #49

BiteCode_dev wrote: post #47

Earlier quoted context omitted.

Do you have a simple example of how this is done correctly? I always heard that but comming from Python internal references would be the way to go so it's not natural to me.

Depending on the shape of the graph (arbitrarily connected, DAG, etc.), it just boils down to whatever convenient way you have of storing lists. Node data in one list. Indices of node parents in another list of the same length. If you need to find children quickly, you can have another list of lists containing children indices. The key is to consider the node’s position in the list as its ID, and refer to nodes by th…

Thanks. So you basically make pointers manually with your own separated stack. Wouldn't make sense to have the ability to just allocate anew stact you dedicate to a graph and let the ownership system deals with it for you? Seems like a missing abstraction.

Re: Rust Memory Management: Ownership vs. Reference Counting

#53

Post by bagol » Tue, Apr 28, 2026, 10:52 AM UTC

Good thing about rust is it forces you to write code in disciplined manner. I remember myself fighting those rules. Until it becomes natural to me and I can detect why the compiler rejected my code without reading the compiler error (for a simple one of course, but not syntax error). And that habit of carefully writing good code without slowing down carries over when I'm writing code in other languages.

Re: Rust Memory Management: Ownership vs. Reference Counting

#54

Post by michalsustr » Wed, Apr 29, 2026, 5:32 PM UTC

BiteCode_dev wrote: post #52

simonask wrote: post #49

Earlier quoted context omitted.

Depending on the shape of the graph (arbitrarily connected, DAG, etc.), it just boils down to whatever convenient way you have of storing lists. Node data in one list. Indices of node parents in another list of the same length. If you need to find children quickly, you can have another list of lists containing children indices. The key is to consider the node’s position in the list as its ID, and refer to nodes by th…

Thanks. So you basically make pointers manually with your own separated stack. Wouldn't make sense to have the ability to just allocate anew stact you dedicate to a graph and let the ownership system deals with it for you? Seems like a missing abstraction.

I recently saw a submission here that does that, by essentially implementing GC in Rust. It is not beginner material though. https://kyju.org/blog/tokioconf-2026/

Edit: also the simplest way how to do cyclic structures is to heap-allocate via Box and leak memory. Box::leak This is also mentioned in the linked article.