[moldavi]

That's why I mentioned one needs to have discipline, to not use that particular solution.

We agree it's not the best solution. And it's easy for us to say that now, after I've spelled out why. You'd be surprised how many people don't know that this can be a problem.

Also, it amuses me that having a simple index into a Vec would be a "convoluted solution". It's the easiest solution of all the alternatives. It can also be risky for privacy.

Compare that to a GC'd language, where the easiest solution (just hold a reference) doesn't introduce privacy risks.

[rowanG077]

Arc is by far the easiest solution. You don't have to deal with indices at all.

[moldavi]

In Rust, people tend to go for the easiest solution that works within the borrow checker, and not workarounds like Rc or Arc. Otherwise, the performance hit means there's little reason to use Rust over much easier languages.

[estebank]

Callinc Rc a workaround is like calling i64 a workaround. It is a type that encodes a certain contract, it's there to be used. The advantage Rust has is that for 95% of your codebase the simple code using stack allocated values and references will be as fast as it can be, and yoi opt-into the slower behavior for the remaining 5% if they are not part of your performance critical path. If it is, then you need to rearchitect things, like you would in other languages. But you can do so after meaauring.

[rowanG077]

You don't have to throw out the baby with the bathwater. A few Arcs to hold onto a Users metadata is hardly going to be in the critical path of the app.

[moldavi]

That's where the discipline comes in: one has to know when it's okay to use the simpler approach (indices into a Vec), and when it's better to use Arcs such as to prevent privacy problems.

[rowanG077]

The point is that we disagree that indices into a Vec is the simple approach. It's much harder. It infects the entire code. Whereas just using a reference count is basically set and forget.