Profiles control how cargo builds. Two built-ins: dev (fast compile, debug info, no opts) and release (opt-level 3). You tune per-profile in Cargo.toml:

[profile.release]
opt-level = 3        # 0-3, or 's'/'z' for size
lto = true           # link-time opt
codegen-units = 1    # fewer units = better opt, slower compile
panic = 'abort'      # or 'unwind'

There's also [profile.dev.package."*"] to optimize deps while keeping your code debuggable — the classic trick for dev iteration speed.

A workspace is a group of related crates sharing one Cargo.lock and one target/ directory — a Rust monorepo primitive:

[workspace]
members = ["adder", "add-one", "shared-utils"]

Dependencies between members use path deps (add-one = { path = "../add-one" }). Benefits: one lockfile (consistent versions), shared build cache (compile once), atomic cross-crate changes. You need it when one project splits into multiple crates — big services split into api/, core/, db/ crates is the canonical shape.

/// Adds one to the input.
///
/// # Examples
/// ```
/// let n = mycrate::add_one(5);
/// assert_eq!(6, n);
/// ```
pub fn add_one(x: i32) -> i32 { x + 1 }

/// comments are documentation — Markdown, compiled into cargo doc HTML. The triple-backtick blocks are doctests: cargo test compiles and runs them. Your examples literally can't rot — a wrong example fails CI. //! documents the enclosing item (module/crate). Also #[doc(hidden)] hides impl details.

cargo install ripgrep downloads the crate, builds its binary targets in release mode, and places them in ~/.cargo/bin (on PATH). It's how the Rust CLI ecosystem distributes tools — rg, fd, bat, cargo-edit.

Publishing: cargo login (API token) → fill Cargo.toml metadata (name, description, license — required) → cargo publish → cargo package previews the upload. Versions are permanent — cargo yank marks a version bad (stops new dependents) but never deletes code, which is why yanking, not deleting, is the only escape hatch.

Features are opt-in capabilities declared in Cargo.toml:

[features]
default = ["json"]
json = ["dep:serde"]
metrics = ["dep:prometheus"]

Users enable with --features metrics or features = ["metrics"] in their dep. In code: #[cfg(feature = "metrics")] gates items — compile only when enabled. It's how crates stay lean: consumers pay only for what they use. cfg also works for #[cfg(test)], #[cfg(unix)] — same attribute, different predicates.

- cargo fmt / rustfmt — the formatter; cargo fmt --check in CI

- cargo clippy — the linter; hundreds of lints, -D warnings in CI

- cargo doc --open — build + open API docs (with your /// comments)

- cargo tree — dependency graph (debugging dup versions)

- cargo add / cargo update — edit deps / bump lockfile

- cargo audit — security advisories against the lockfile (third-party)

- cargo bench (nightly) / criterion — benchmarking

Interviewers probing "have you shipped Rust" often land on clippy/rustfmt in CI plus cargo tree for dependency debugging.