While participating in this thread on the good ol' twitter, we came to the topic of data ownership modeling.
We came to this topic through the dreaded question: When is it right to use Rcs, Arcs vs reshaping the program's architecture?
My understanding is that, it's complicated, like many things in our domain😅. It takes flair, expertise, trials and errors to know that using one or the other solutions is the right answer to the problem.
More often that not, beginners will feel this intense pressure not to use them. I for one, know that they are correct to use but I will never know if I could have down better.
Out of this realization, I believe (and that's pure belief, a leap of faith of sorts), that by exposing those memory management primitives, Rust opens up a field of discussion (that was initially reserved to the garbage collector or the compiler) around modelling ownership. The borrow checker ensures that your ownership model is sane, not that it's appropriate.
The same way the GoF published the design patterns for OOP by studying OO Programs and abstracting away the various solutions found here and there, there may be an opportunity here to study many rust programs and focus on the data modelling solutions they employ.
I give you an example. ECS was mentioned during the discussion, for game dev. But do we recognize this pattern somewhere else? It it being used to solve similar problems in different problem spaces? What can we learn from this pattern, it's strength, it's weakness, where it can be applied, examples of implementations, novel or in the wild etc...
You see where I'm going with it.
A Fool's Errand or a noble quest?