Use Arc Instead of Vec
youtu.be
Rust lets you do efficient reference-counted strings and dynamic arrays using Arc basically just as easily as their owning (and deep-cloning) equivalents, St...

Rust lets you do efficient reference-counted strings and dynamic arrays using Arc basically just as easily as their owning (and deep-cloning) equivalents, String and Vec respectively. So why not use them as a reasonable default, until you actually need the mutability that String and Vec provide? Get into the weeds with me here, feat. some cool visualizations, with special guest appearance from Box.

This video assumes some familiarity with Rust and its core smart pointer types, namely Vec/String/Rc/Arc/Box, along with data structures like HashMap and BTreeMap, and traits like Clone, Hash, Ord, and serde::{Serialize, Deserialize}.

serde feature flag for Rc/Arc
Arc docs
Vec docs
Smart pointers in Rust • Crust of Rust
animations

  • @[email protected]English
    4•2 years ago

    I think the video misses a lot of points. Most of the time you just want one owned String and then pass around a lot of &str references. For the use case they describe where lifetimes make this hard, I don’t think the solution is to use Arc at all, but instead use u32 or similar for your id instead of a string id. That is way cheaper to copy around.

    There are times to use a Box or Arc str instead, but those are not as common as just string references or u32 ids.

    • @[email protected]OPEnglish
      1•2 years ago

      I’m confused by your response. What are you saying is cheaper to copy compared to what?

      • @[email protected]English
        2•2 years ago

        It is cheaper to copy a Id(u32) then a Id(Arc<str>) The Arc requires a lock, incrementing a counter and copying a pointer. The Id is only a copy of a u32. For the use case the video describes it makes more sense to use simple IDs and not stringy typed ids for passing around everywhere to avoid this extra cost (as well as the cost of comparing strings when you need to fetch the data the id is meant to represent).

  • @[email protected]English
    3•2 years ago

    I believe the video is somewhat incorrect: Arc (and Rc) need a reference count, which you missed in your description of the overhead. (EDIT: You mentioned this later in the video. )

    The downside of all of Arc or Rc is of course (as you pointed out towards the end of the video) that you need to do all that reference counting and store the reference count (as I mentioned above). A box of a slice would indeed be cheaper. But if the data is static (or will at least live for the rest of the program), you might consider just leaking it (Box::leak) to get a static lifetime reference. That can then be cheaply shared.

    • @[email protected]OPEnglish
      1•2 years ago

      I want to be clear that I didn’t make this video. I just thought it was worthy of sharing as someone who doesn’t have a good handle on Rust or best practices in using Rust.

    • @[email protected]English
      2•2 years ago

      Arc<String> is roughly equivalent to Arc<Vec<char>>.

      Nitpick: it’s Vec<u8>, not Vec<char>.

    • @MetricExpansionEnglish
      1•2 years ago

      Passing around references works, but then you have to deal with ownership issues. Often the motivation for cloning a Vec or String is just to avoid dealing with lifetimes and to get ownership, but the mutability isn’t actually required. In these situations I think the video’s recommendation to use an Arc is actually a good one.