The borrow checker is solid.
The communication with it, is a UX fail.
As indicative by the tutorials that write pseudo code to try to teach you how it works using named scopes.
By now, I get how it works but it's hard to predict in a when you're not exactly sure how to solve certain technical issues, or even how the final design of an API of several modules will look like.
Forcing you go back and forth between lifetimes, implementations and what not. two steps forward, eleven back.
It's a failure that the borrow checker does not adapt to what I am trying to achieve instead of telling me it's impossible - when I am very much aware, it's possible.
Ideas: Figure out what variations of smart pointers and mutexes will work in combination to do what I am trying to achieve and make it happen - this essentially gets rid of the borrow checker as your code becomes reference counted instead of compile error. Performance and execution becomes unpredictable as you have no idea what's going to happen once you execu