Oh my I'm really operating on limited brain capacity today my dear readers. Hope my question answering isn't filled with rubbish <3

Yesterday's questions answered

• I had a very busy day and didn't have time to write something extensive. But do not fear: I will dedicate an entire article to the topic of ownership and scope.
• Writing unit tests in Rust are easy:

pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_add() {
    assert_eq!(add(1, 2), 3);
    }
}

You can run cargo test to run the suite.

• A quick Google around didn't help me find anything out about access the stack managed by rust. Buuuut the alloc module from the standard library provides an API to interact with items on the heap.
• Primitives implement the Copy trait which means that their values are copied when a reassignment takes place. Non-primitives do not implement this trait. In computer science terms: primitives possess copy semantics and non-primitives possess move semantics.
• A trait is implemented for an unknown type referred to in the signature as Self. I guess any valid type should be able to implement a trait.
  • impl is not bound to a single struct. I think the difference between an impl and a trait is that a trait doesn't need to know what's implementing it.

Today's open questions

My house mates had a couple of questions to kick us off.

• Are there different ways to cast at compile and runtimes?
• Are there deconstructors in Rust?

Projecting in Rust

In the Python world, the language around packaging can be confusing. Is this a library or package. Is this a package or module? Is this a project? Da hell is a submodule? Absolute or relative imports? (Yes, FastAPI you are wrong here!).

Rust has gone for clear semantics: crates, mods, packages and paths. If you reuse code locally stored in different subfolders of your project, you're probably going to want to make a crate. Similar to the export keyword in JavaScript, crate allows you to make code from a mod importable.

mods are a useful way to group code into logical blocks that may want to be exported. You can have nested mods and mods can be public or private.

paths are used by crates to access mods. paths are also used in import syntax.

Finally, packages are (I assume) the way to ship your code to another machine.

We all make mistakes: don't panic!

Errors in Rust are not raised. Either your program will panic and crash or you can predict where errors will occur and spot them in functions that return Result types. Similar to Option, you have a happy and sad path here. Handling errors returned in Result types can be done in a variety of ways:

• Using match statements
• Chaining the function call with .expect
• Ignoring them and writing bad code (using unwrap, for example).

match statements are the Rust way of doing things, while expect offers a very light weight API, similar to catch in JavaScript. Interestingly, error types are expressed through the kind method of an Error type. Combining kind with match offers a succinct way to handle multiple errors.

That's it for today folks: I'm knackered, goodnight!