Hacker News Reader

> Not understanding the lifetimes of objects is what makes shared mutability hard.

Well, no; in my experience the difficulty overwhelmingly comes from thinking about the semantics. I.e.: these two clients currently share a mutable object; should they observe each others' mutations? Or: if I clone this object, will I regret not propagating the change to other clients?

View on HN

If you understand how it will work then that is just a decision to be made and a decision (although design is not necessarily easy) isn't what I would call hard: it is the ordinary work. By difficulty I mean bugs and bugginess, and bugs happen in this area because there are unintentional race conditions on the mutability. Total immutability is merely one way to force yourself to understand it, if those two clients need to observe the modifications then you have to propagate the changes manually instead of relying on shared memory semantics. But worse than that, even if you decide that they should observe the changes, then you can often end up with tearing if you are changing multiple properties non-atomically. That is a lifetime issue: the mutable reference is allowed to coexist at the same time as an immutable reference. In rust you cannot share an ordinary reference to have runtime observability like that, once shared the object becomes immutable. This forces you to use internal mutability via a RefCell and the exclusive/shared reference is enforced at runtime to eliminate tearing. Lifetimes of these borrows matter and how they matter depends on the choice of semantics, but I wouldn't call the choice the hard part.

Reply on news.ycombinator.com