/rust-dev

name: rust-dev
description: Day-1 guide to building well in Rust - ownership, errors as values, String vs &str, Box/Rc/Arc, anyhow vs thiserror, and a crate shortlist (tokio, serde, axum, sqlx). Use when starting a Rust project, fighting the borrow checker, or picking crates.
metadata:
  version: "0.9.0"
  categories: "development"
  topics: "rust, ownership, cargo, crates, tokio"
  upstream: "rust@1.99.1, tokio@1.54.1, axum@0.8.9, reqwest@0.13.5, sqlx@0.9.0, jiff@0.2.39, kache@2.0.0, dist@0.34.0, release-plz-action@0.5.148, cargo-zigbuild@0.24.1, insta@1.49.0"
  openclaw:
    homepage: https://github.com/tenequm/skills/tree/main/skills/rust-dev
    emoji: "🦀"

Rust Development - Day 1

A practical foundation for writing Rust apps well from the first commit. Not a textbook. Focuses on the differences from other languages, the day-1 decisions that shape everything else, and the small set of crates that cover most real apps.

When to Use

• Starting a new Rust project (CLI, service, library)
• Coming to Rust from Python, JavaScript, Go, Java/C#, or C++
• Choosing between owned/borrowed types, smart pointers, trait objects vs generics
• Picking error handling strategy (`anyhow` vs `thiserror`)
• Deciding which crates to reach for
• Configuring a minimal but opinionated `Cargo.toml`, clippy, and rustfmt

Day-1 Setup

# 1. Install the toolchain (rustup is the toolchain manager)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 2. Confirm components (rustfmt and clippy ship with stable, rust-src enables IDE features)
rustup component add rustfmt clippy rust-src

# 3. Create a project
cargo new my-app          # binary (src/main.rs)
cargo new --lib my-lib    # library (src/lib.rs)

# 4. The dev loop (memorize these four)
cargo check     # fast type-check, no codegen
cargo run       # build and run (binary)
cargo run -- --verbose in.txt   # args after `--` go to your program, not to cargo
cargo test      # build and run tests (incl. doctests)
cargo clippy --all-targets   # lint, incl. tests/ and benches/ (run before pushing)
cargo fmt       # format

# 5. Manage dependencies without editing Cargo.toml by hand
cargo add tokio --features full
cargo remove tokio
cargo update                 # recompute Cargo.lock within existing semver ranges

# 6. Update the toolchain when a new stable ships (every six weeks)
rustup update

`cargo update` only moves within the version ranges already in `Cargo.toml`. Crossing a breaking version (`1.x` to `2.0`) needs a `Cargo.toml` edit or `cargo add <crate>@2`. For a `0.x` crate - most of the shortlist below - the minor number is the breaking one: Cargo treats versions as compatible when "their left-most non-zero major/minor/patch component is the same", so `axum` `0.8` to `0.9` is as breaking as `1.x` to `2.0`.

When a program panics, run it again with `RUST_BACKTRACE=1 cargo run` to see the call stack that led there - the panic message suggests it, and it is the first thing to reach for.

**rust-analyzer is mandatory.** It is the language server every editor uses (VS Code, Zed, Neovim, Helix, RustRover uses its own engine but is comparable). In VS Code, install the `rust-analyzer` extension and set `rust-analyzer.check.command` to `"clippy"` so you get lint feedback on save.

**Want a file watcher later?** `cargo install --locked bacon`, then run `bacon` in your project. Not needed on day 1.

The Rust Mental Model in 5 Ideas

Rust trades two things you take for granted in most languages (a garbage collector and exceptions) for compile-time guarantees about memory, data races, and error handling. The shape of the language follows from that trade.

1. Ownership: every value has exactly one owner

Think of values like physical objects. A book, a file, a network connection. At any moment, **one variable owns it**. You can:

• **Move it**: `let b = a;` hands ownership to `b`. `a` is gone.
• **Borrow it immutably**: `&a` lets others look at it. Many readers allowed.
• **Borrow it mutably**: `&mut a` lets one person modify it. Exclusive access.
• **Clone it**: `a.clone()` makes a deep copy. Both keep their own.

When the owner goes out of scope, the value is dropped (memory freed, file closed, lock released). No GC, no manual `free`. This is RAII, enforced by the compiler.

2. Aliasing XOR mutability

At any moment, a piece of data has **either**:

• one mutable reference (`&mut T`), **or**
• any number of immutable references (`&T`),

never both. This single rule is what eliminates data races and most use-after-free bugs. The borrow checker enforces it. When it complains, it is telling you your data ownership story is unclear, not that the language is being difficult.

3. Errors are values, not exceptions

There is no `try`/`catch`. Functions that can fail return `Result<T, E>`. Functions that can return nothing useful return `Option<T>`. The compiler forces you to handle both. The `?` operator propagates errors up the call stack with one character:

fn read_config() -> Result<Config, anyhow::Error> {
    let text = std::fs::read_to_string("config.toml")?;  // ? = early-return on Err
    let config = toml::from_str(&text)?;
    Ok(config)
}

There is no `null`. `Option<T>` is `None` or `Some(value)`. The compiler will not let you forget the `None` case.

4. Traits are not Java interfaces

A `trait` defines behavior. Types `impl` traits. So far so familiar. The differences:

• **Static dispatch is the default.** When you write `fn f<T: Display>(x: T)`, the compiler generates a separate copy of `f` for each concrete `T` you call it with (monomorphization, like C++ templates). Zero runtime overhead.
• **Dynamic dispatch is opt-in** via `dyn Trait` (typically `Box<dyn Trait>` or `&dyn Trait`). One vtable lookup per call.
• **No inheritance.** Traits compose. If you find yourself reaching for `Deref` to "extend" a type, stop and use composition or an enum.
• **Orphan rule**: you can `impl YourTrait