this post was submitted on 05 Apr 2024
43 points (95.7% liked)
Learning Rust and Lemmy
231 readers
1 users here now
Welcome
A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.
Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.
Running Projects
- Rust for Lemmings Reading Club (portal)
- Rust beginners challenges (portal)
- Heroically Helpful Comments
Policies and Purposes
- This is a place to learn and work together.
- Questions and curiosity is welcome and encouraged.
- This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
- This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.
See also:
Rules
- Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
- Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
- Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
- See the Lemmy Code of Conduct
- Where applicable, rules should be interpreted in light of the Policies and Purposes.
Relevant links and Related Communities
- Lemmy Organisation on GitHub
- Lemmy Documentation
- General Lemmy Discussion Community
- Lemmy Support Community
- Rust Community on lemmy.ml
- Rust Community on programming.dev
Thumbnail and banner generated by ChatGPT.
founded 9 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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:
MyType
orself
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.&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.&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 ofself
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 forArc<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.
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.
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!
I would recommend changing rust-analyzer "check command" setting from "check" to "clippy", then you'll see clippy hints in your editor.
Cheers! So clippy is worth it then?
Oh definitely, it'll point out if you can do something simpler. The default are fine as well. Honestly don't know why it's not just the default to use it.
Cheers! Will do!