• let mut! (also not a macro)
• mutability means exclusive access. LIKE LOCKS. FOR DOORS.

• as <type>

• 'blocks delimit a scope'
• 'blocks return a value'
• use blocks to release resources

cool

• if
• loop, while, for

wow this resource was worth it just for introducing me to rust-analyzer.

• stack! this is where you put plates. things on the stack only live as long as the function they are inside.
• heap! this is where you find needles in O(1). things can live here until they are deallocated. this has to happen deliberately.
• flavors: manual memory management, automatic memory management (garbage collection [java, go], reference counting [python, swift])
• Rust does manual memory management via ownership. so neoclassical.

• ownership is used for tracking when memory is valid and when it is dropped.
• the lifetime of a variable is the time when references to it are valid.

> "These are still things that disintegrate. What is the indestructible nature?" - some monk to Joshu

• "Every reference is a borrow, and each borrow has a lifetime. That lifetime spans from when the variable is created to when it is destroyed."

Which is to say, if you have a reference to something, you're borrowing it (mutably or immutably). you can borrow it only so long as that thing exists. And thus a borrow has a lifetime spanning the birth and death of the thing.

• the borrow checker makes sure every reference has a lifetime WHOLLY contained in the borrowed value's lifetime.

fn example<'a>(x: &'a u32) {
   let y: &'a u32 = &x;
}

does this mean y is a reference to a reference?

• generics: <'a>
• 'static means "referred to data will live for the duration of the program"

constants:

let msg: &'static str = "hello, wordl!";

• anywhere type annotation can go, an explicit lifetime can go too.
• lifetime elision. Compiler guesses based on rules.

• I think I misunderstood something before. Variables don't own things. Scopes own things and scopes borrow things. That's helpful.
• copy. Some types implement the copy trait. These types types get copied instead of being moved, which means you can keep using it in both 'places'. ie:

let x: u32 = 10;
println!("x is {x}");
println!("x*2 is {}", x*2);

normally, println! would take ownership of x, meaning we couldn't reference x anymore after the completion of println!'s scope. But because x 'is Copy' here, we can keep using it because it is copied into the scope of println! instead of moved. Realizing this in vivo requires understanding the types and their respective traits as you pass them around.

• these are essentially anonymous functions:

let y: u32 = 10;
let annotated = |x: u32| -> u32 { x + y };
let inferred = |x| x + y;

println!("annotated: {}", annotated(32));
println!("inferred: {}", inferred(32));

• closures can reference values outside their scope. they can also capture and use them. By, say, getting a value from outside the scope, and incrementing it. But the closure must be mut if it captures a mutable variable. It's capturing a mutable variable (the variable becomes part of the closure) and it, thus the closure is changing.
• functions can return closures:

fn print_msg<'a>(msg: &'a str) -> impl Fn() + 'a {
        let printer = move || {
          println!("{msg}");
        };
        printer
}

fn make_counter() -> impl FnMut() {
   let mut count = 0;
   let increment = move || {
       count += 1;
       count
   };
   increment
}

let adder = |a: u32, b: u32 | a + b;

• struct fields
• struct impl blocks

struct CrewMember {
  name: String,
  age: u32,
  odors: Vec<String>,
}

impl CrewMember {

  pub fn describe(&self) {

  println!("{} is {} and smells like {:?}", self.name, self.age, self.odors)

  }

}

• good
• variants: field by position; fields by name; unit variant
• pattern matching

enum Weekdays {
     Monday,
     Tuesday,
     Wednesday,
     Thursday,
     Friday,
}

enum Result<T, E> {
     Ok(T),
     Err(E)
}

• in a block delimited by braces:

pub mod math {

    pub fn add(x: u32, y: u32) -> u32 {
        x + y
    }
}

• in a file at the level of main.rs with the name of the module (ie math.rs). must add pub mod math; to main.rs file.
• in a folder (ie math) with a mod.rs file containing the code.

• integration tests can only consume the public api of your library. ex:

use my_library::plus;

#[test]
fn test_addition() {
   assert_eq!(plus(10, 20), 30);
}

• i hadn't heard of such a thing:

/// Adds things
///
/// ```
/// use playground::plus;
/// assert_eq!(30, plus(10,20));
/// ```
pub fn plus(x: i32, y: i32) -> i32 { x + y }

• formatter: cargo-fmt. run with: cargo fmt
• linter: clippy. run with: cargo clippy
• its usually good to treat clippy warnings as errors.

• crates.io
• add a dependency to your project with (serde is an example): cargo add serde.
• if you want a specific verion, add serde = "1.0.154" to Cargo.toml
• semver: semantic versioning. MAJOR.MINOR.PATCH. changes to MAJOR imply incompatible API changes. Changes to MINOR imply functionality added in a backward-compatible manner. Changes to PATCH imply backward-compatible bug fixes.

• for defining shared behavior
• basically a collection of methods, either abstract or composed of other trait methods.
• abstract methods are then implemented depending on the type

ex:

trait KeyValueStore {

// must be implemented by structs with the KeyValuestore trait
    fn set(&mut self, key: &str, value: Vec<u8>); // I think the value is just an example
    fn get(&mut self, key: &str);
    fn lock(&mut self, key: &str);
    fn unlock(&mut self, key: &str);

    // composed of the above methods
    fn get_and_set(&mut self, key: &str, value: Vec<u8>) -> Option<Vec<u8>> {

       self.lock(key);
       let old_value = self.get(key);
       self.set(key, value);

       self.unlock(key);
       old_value

    }
}

Note: everything is public by default.

• use methods from a trait on a type that impls it.
• accept the trait as parameters to a function or return type
• use them as part of genenics

• generics allow code that accepts one or more type parameters. ex:

fn max<T: PartialOrd>(x: T, y: T) -> T {
    if x > y {
       x
    } else {
       y
    }
}

fn main() {
    let a = 5;
    let b = 12;
    let c = 1.5;
    let d = 8.22;

    println!("Larger of {} and {}: {}", a, b, max(a, b));
    println!("Larger of {} and {}: {}", c, d, max(c ,d));

}

• generic structs

struct Point<T> {
    x: T,
    y: T,
}

struct Point2<X, Y> {
    x: X,
    y: Y,
}

fn main() {

    let integer_point = Point { x = 1, y = 2};
    let float_point = Point { x = 1.2, y = 3.33};

    let mixed_point = Point2 { x = 1, y = 1.0}

}

• generic enums and traits. ex:

use std::ops::Div;

enum Result<T, E> {
    Ok(T),
    Err(E),
}

// a 'generic' divide
fn divide<T: Div>(x: T, y: T) -> T::Output {
   x / y
} 

• Result and the ? operator. If ? is used, the calling function must return a Result.
• panics. reserved for exceptional situations where it is undesirable or impossible to continue executing the program. to be used sparingly and in exceptional circumstances. In most cases, Result is better.

• concurrency and parallelism are not necessarily the same.
• async defines asynchronous functions. they always return a Future. This is a value that is not available yet, but will be at some point. ex:

async fn fetch_data() -> Result<String, String> {
    // ...
}

This functions says it returns a Result, but this is rust hiding some details. The function doesn't return anything until you await it. When a future is awaited, the current task is suspended, allowing other tasks to run concurrently. ex:

async fn main() {
    match fetch_data().await {
        Ok(data) => println!("Data: {}", data),
        Err(error) => println!("Error: {}", error),
    }
}

• async runtimes in rust: Tokio, but there are other options out there.