Hey!

I’m a professional software engineer with several years of experience using Rust. Unfortunately I don’t really have the time to contribute to Lemmy directly myself, but I love teaching other people Rust so if:

  • You are curious about Rust and why you should even learn it
  • You are trying to learn Rust but maybe having a hard time
  • You are wondering where to start
  • You ran into some specific issue

… or anything to do with Rust really, then feel free to ask in the comments or shoot me a PM 🙂

  • maegul (he/they)@lemmy.mlM
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    7 months ago

    So far, I’m not sure I’m satisfied with whatever I’ve read about the borrow checker.

    Do you have any sort of synthesis of the core ideas or principles or best practices that work for you?

    Personally I’m partial to core or essential principles that seem esoteric at first glance but become clearer with more practice and experience.

    Otherwise, are there any pain points in getting better at rust that you think are worth just sort of not caring too much about and taking a short cut around until you get better? (Eg: just clone, don’t feel bad about it)


    Otherwise, thanks for this! Feel free to subscribe and chime in whenever people have questions.

    • SorteKaninOPA
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      7 months ago

      Do you have any sort of synthesis of the core ideas or principles or best practices that work for you?

      I think it’s hard to give some sort of master theorem because it really comes down to what you are doing.

      That said, start by considering ownership. As you start, avoid creating types with non-static references inside of them i.e. keep to types that own their contents. Types with references requires you to use lifetimes and you’ll be better off getting used to that later. And frankly, it’s often not necessary. The vast majority of the types you’ll ever make will fully own their contents.

      Now when you make functions or methods, think of the three options you can use when taking parameters:

      1. Take ownership, i.e. MyType or self for methods. Use this if your function needs to own the data, often because it needs to take that data and put it into another value or otherwise consume it. Honestly this is the least common option! It’s quite rare that you need to consume data and not let it be available to anyone else after the function call.
      2. Take a shared reference i.e. &MyType or &self for methods. Use this is your function only needs read access to the data. This is probably the most common case. For instance, say you need to parse some text into some structured type; you’d use &str because you just need to read the text, not modify it.
      3. Take a unique reference, i.e. &mut MyType or &mut self. You’ll need this if you want to refer to some data that is owned elsewhere but that you need temporary exclusive (unique) access to, so that you can modify it. This is often used in methods to be able to modify private fields of self for example. You need to think about the fact that no one else can have a reference to the data at the same time though. Often this is not a problem, but sometimes you need to be able to mutate stuff from multiple different places. For that, you can consider either passing ownership around, for instance via channels and sending messages or you could reach for Arc<Mutex<T>> to allow mutation through shared references with a tiny bit of runtime performance cost.

      When you think in terms of ownership, the borrow checker becomes easy to understand. All it’s doing is checking who owns what and who is borrowing what owned data from who and are they giving it back when they said they would?

      I hope that helps but again, it’s a very general question. If you give me a concrete case I could also give more concrete advice.

      PS: Abso-fucking-lutely just clone and don’t feel bad about it. Cloning is fine if you’re not doing it in a hot loop or something. It’s not a big deal. The only thing you need to consider is whether cloning is correct - i.e. is it okay for the original and the clone to diverge in the future and not be equal any more? Is it okay for there to be two of this value? If yes, then it’s fine.

      • maegul (he/they)@lemmy.mlM
        link
        fedilink
        English
        arrow-up
        2
        ·
        7 months ago

        This is actually a decent synthesis. I personally didn’t learn anything from it per se (not a criticism), but this sort of break down has been lacking from whatever I’ve consumed so far (mostly the Brown university version of the book) and I think it’s good and helpful.

        So far I’ve found the book (out the brown University version, because there are differences AFAICT) to be too front loaded on ownership.

      • maegul (he/they)@lemmy.mlM
        link
        fedilink
        English
        arrow-up
        2
        ·
        7 months ago

        PS: Abso-fucking-lutely just clone and don’t feel bad about it. Cloning is fine if you’re not doing it in a hot loop or something. It’s not a big deal. The only thing you need to consider is whether cloning is correct - i.e. is it okay for the original and the clone to diverge in the future and not be equal any more? Is it okay for there to be two of this value? If yes, then it’s fine.

        Nice!

        I haven’t used clippy (just rust analyser so far, and the compiler of course) … but I wonder if it’d be nice to have some static analysis that gives some hints about how costly a clone is likely to be, just so you could have some confidence about not cloning where it will actually hurt.

        Also, thanks for the reply!

        • SorteKaninOPA
          link
          fedilink
          English
          arrow-up
          3
          ·
          7 months ago

          I would recommend changing rust-analyzer “check command” setting from “check” to “clippy”, then you’ll see clippy hints in your editor.