> Maybe there's a style I haven't learned yet where you start out with Arc everywhere, or Rc, or Arc<Mutex<T>>, or whatever, and get everything working first then strip out as many wrappers as possible?
I wouldn't recommend that. It's easy to end up with a fundamentally flawed architecture impossible to refactor out of.
In general as long as you stick to keeping data ownership as high up in the call stack as possible everything should slowly fall into place.
Think functional core imperative shell.
Your main has services, dependencies, data, and just makes calls that operate on data without trying to make deeper owned objects that are inherently hard to keep references to.
Agreed. IMO, anywhere you butt heads with the borrow checker is a place where you’d have to by hyper nitpicky about user after free or memory leaks in C or C++, just without the compiler shouting at you to fix it.
I wouldn't recommend that. It's easy to end up with a fundamentally flawed architecture impossible to refactor out of.
In general as long as you stick to keeping data ownership as high up in the call stack as possible everything should slowly fall into place.
Think functional core imperative shell.
Your main has services, dependencies, data, and just makes calls that operate on data without trying to make deeper owned objects that are inherently hard to keep references to.