Rust Pro

Common Ownership Patterns

// Transfer ownership
fn process(data: Vec<u8>) { /* owns data, dropped at end */ }

// Borrow immutably
fn analyze(data: &[u8]) -> usize { data.len() }

// Borrow mutably
fn transform(data: &mut Vec<u8>) { data.push(0); }

// Return owned data
fn create() -> Vec<u8> { vec![1, 2, 3] }

Avoiding Borrow Checker Fights

• Structure code so borrows have clear, non-overlapping scopes
• Split structs if one field's borrow conflicts with another's mutation
• Use indices instead of references into collections you need to mutate
• Consider interior mutability (RefCell, Mutex) when shared mutable state is truly needed

Lifetimes

When Annotations Are Needed

• Function signatures with references in both input and output
• Struct definitions that hold references
• Impl blocks for structs with lifetime parameters

Lifetime Elision Rules

1. Each input reference gets its own lifetime parameter
2. If there is exactly one input lifetime, it is assigned to all output lifetimes
3. If one input is &self or &mut self, its lifetime is assigned to all outputs

Practical Patterns

// Explicit lifetime: output borrows from input
fn first_word(s: &str) -> &str {
    s.split_whitespace().next().unwrap_or("")
}

// Struct holding a reference
struct Parser<'a> {
    input: &'a str,
    position: usize,
}

// When in doubt, make it owned
// Use String instead of &str in structs unless you have a clear lifetime story

'static Lifetime

• Means the data lives for the entire program duration
• String literals are 'static: let s: &'static str = "hello";
• Required by many async runtimes for spawned tasks
• Owned types (String, Vec) satisfy 'static bounds because they own their data

Error Handling

The Error Hierarchy

• Use Result<T, E> for recoverable errors; never panic for expected failures
• Use Option<T> for absence of a value (not an error condition)
• Reserve panic! for programmer errors and unrecoverable invariant violations

Custom Error Types

use thiserror::Error;

#[derive(Error, Debug)]
pub enum AppError {
    #[error("Database error: {0}")]
    Database(#[from] sqlx::Error),

    #[error("Not found: {entity} with id {id}")]
    NotFound { entity: &'static str, id: String },

    #[error("Validation failed: {0}")]
    Validation(String),

    #[error(transparent)]
    Unexpected(#[from] anyhow::Error),
}

Error Handling Best Practices

• Use thiserror for library error types (structured, typed errors)
• Use anyhow for application-level error handling (convenient, context-rich)
• Add context with .context("what was being done") from anyhow
• Use ? operator for propagation; avoid explicit match on every Result
• Map errors at boundaries (e.g., convert DB errors to API errors in the controller layer)

Async Rust

Runtime Choice

• Tokio: most popular, full-featured, best ecosystem support
• async-std: simpler API, mirrors std library naming
• Choose one runtime per project; do not mix

Async Patterns

// Spawning concurrent tasks
let (a, b) = tokio::join!(fetch_users(), fetch_orders());

// Spawning independent tasks
let handle = tokio::spawn(async move {
    process(data).await
});
let result = handle.await?;

// Select first to complete