4 ms·

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

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 4y ago
Arc is by far the easiest solution. You don't have to deal with indices at all.
- moldavi 4y ago
  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.
  - rowanG077 4y ago
    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 4y ago
      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 4y ago
        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.
  - estebank 4y ago
    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 4y ago

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

moldavi 4y ago
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.
- rowanG077 4y ago
  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 4y ago
    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 4y ago
      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.
- estebank 4y ago
  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.