this post was submitted on 07 Feb 2024
21 points (95.7% liked)

Learning Rust and Lemmy

391 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


Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. 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.
  4. 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

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. 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.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities


Thumbnail and banner generated by ChatGPT.

founded 9 months ago
MODERATORS
 

Hi All! Welcome to the Reading Club for Rust's "The Book" ("The Rust Programming Language"). This is week 1 (the beginning!!).

Have a shot at going through "the reading" and post any thoughts, confusions or insights here

"The Reading"

The Twitch Stream

What's Next Week?

  • Chapters 3 and 4
  • Start thinking about challenges or puzzles to try as we go in order to get some applied practice!
    • EG, Advent of Code
    • Maybe some basic/toy web apps such as a "todo"
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 9 months ago (1 children)

This will make more sense once we (this community) get to the 4th week/session and properly get into ownership, but lemme try to explain anyways:

A variable without a & in front is moved into the [function's] scope.

Upon exiting a scope, Rust automatically drops/de-allocates any variables that were owned by/moved into said scope.

This is why you need to either

  1. pass by ref / have the scope borrow a reference to the variable, or

  2. have your function return the variable/object/memory handle that was moved into it

when you want a variable/some data to "out-live" being passed as argument to a function call.

Most often you will use 1), but there are some cases where it can be much nicer to move things "into" a function call and store what you "get back out" (i.e. the return value). Using a "[Type-]State" pattern/approach is a good example of such a case (here's a better explanation than I can give in a lemmy comment).

Example:

struct Unauthenticated;
struct Authenticated { name: String };

impl Unauthenticated {
    fn login(self, username: String) -> Authenticated {
        Authenticated { name: username }
    }
}

pub fn main() {
    let un_authed_user = Unauthenticated::new();
    let authed_user = un_authed_user.login("Alice"); // `un_authed_user` has effectively been moved into `authed_user`
}

Here, we as programmers don't need to worry about making sure un_authed_user gets cleaned up before the program exits, and we don't need to worry about data that could have been stored inside un_authed_user being freed too early (and thus not being available to authed_user).

Admittedly, this is a contrived example that doesn't really need to worry about ownership, it's just the bare minimum to illustrate the idea of moving data into and then back out of a function scope. I don't know of a small enough "real-world" example to give here instead.

[–] freamon 2 points 9 months ago (1 children)

Thank you.

I think there's more to it though, in that simple values aren't moved, they're always copied (with any & in front indicating whether it's the value to copy or the address)

To illustrate:

fn how_many(a: u32, fruit: String) {
    println!("there are {} {}", a, fruit);
}


fn main() {
    let a=4;
    let fruit = String::from("Apples");
    how_many(a, fruit);

    println!("the amount was {}", a);         // this works
    println!("the fruit was {}", fruit);      // this fails
}

The 'a' was copied, and the 'fruit' was moved.

[–] [email protected] 2 points 9 months ago

Correct! Values that can be copied are copied, and those that aren't are moved.

All primitive data types are copyable (or "are Copy ", which will make more sense once we get to Traits). I think arrays of primitives are as well? Most everything else isn't by default.

One of my favorite parts of Rust is that to make something copyable, you "just" implement the Copy trait for that thing.