DEV Community: mihir mohapatra

I Built a Production-Oriented Multi-Provider AI Chatbot in Rust — Here's How

mihir mohapatra — Sun, 31 May 2026 05:49:53 +0000

Most AI chatbot tutorials reach for Python. FastAPI, LangChain, a quick requests.post — done in 20 minutes. And that's fine for prototyping. But when I wanted to build something I'd actually put behind a real API — something with proper async concurrency, typed errors, and zero GC pauses — I reached for Rust instead.

This is a writeup of chatbot, a production-oriented Rust backend that unifies Claude, OpenAI, and Ollama behind a single interface — with a Web UI, CLI mode, and Docker support baked in.

Why Rust for an AI Backend?

It's a fair question. LLM API calls are network-bound, so why does the backend language even matter?

A few reasons:

Predictable latency. No GC pauses under load means P99 response times stay stable when you're handling dozens of concurrent conversations.
Memory efficiency. Each async task in Tokio is dramatically cheaper than a Python thread. You serve more users per instance.
Type safety. Rust's ownership model makes API contracts explicit. You can't accidentally share mutable conversation state across requests — the compiler enforces it.
Long-term maintainability. Explicit types and explicit error handling make the code self-documenting.

For LLM apps specifically: yes, 95% of your wall-clock time is waiting for the model to respond. But the other 5% — routing, state management, provider selection, connection handling — is all yours to control. Rust makes that part bulletproof.

What It Does

Connects to Claude (Anthropic), OpenAI, or Ollama (local) via a unified chat interface
Serves a Web UI at http://localhost:8080 by default, or runs in CLI mode
Maintains per-session conversation history in memory
Supports runtime provider switching via a connect-first flow
Ships with a Dockerfile for containerized deployment
Supports OpenRouter as an OpenAI-compatible provider

Architecture Overview

User (Browser or CLI)
        │
        ▼
  Axum HTTP Server (web.rs)
        │
        ├──▶ Conversation State (Arc<Mutex<Vec<Message>>>)
        │
        └──▶ Runtime Config (config.rs)
                    │
                    ▼
            ChatClient (client.rs)
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
        Claude   OpenAI   Ollama
         API      API      API

The project has a clean five-module layout in src/:

src/
├── main.rs          # Startup routing + CLI loop
├── config.rs        # Provider enum + env/runtime config
├── client.rs        # Provider-specific HTTP clients
├── conversation.rs  # In-memory chat state model
└── web.rs           # Axum routes, connect flow, chat API

Each module has exactly one responsibility. No god objects, no tangled imports.

The Provider Abstraction

The heart of the project is client.rs. Instead of sprinkling provider-specific logic everywhere, all outbound AI calls go through a single ChatClient that dispatches based on the active provider.

The key insight: Claude uses the Anthropic native API format, while OpenAI and Ollama both speak the OpenAI-compatible schema. Separating these two code paths keeps the provider logic honest — you're not faking compatibility where there isn't any.

// Simplified concept from client.rs
pub enum Provider {
    Claude,
    OpenAI,
    Ollama,
}

pub struct ChatClient {
    pub provider: Provider,
    pub model: String,
    pub base_url: String,
    pub api_key: Option<String>,
    pub max_tokens: u32,
    pub system_prompt: String,
    pub http: reqwest::Client,
}

When you send a message, the client picks the right HTTP contract:

pub async fn send(&self, messages: &[Message]) -> Result<String> {
    match self.provider {
        Provider::Claude => self.send_claude(messages).await,
        Provider::OpenAI | Provider::Ollama => self.send_openai_compat(messages).await,
    }
}

This means adding a new provider (Gemini, Cohere, etc.) in the future is a matter of adding one arm and one method — the rest of the application stays untouched.

Shared Conversation State

Multi-turn chat requires persistent message history. In Rust's async model, sharing state across request handlers requires explicit synchronization. The project does this with Arc<Mutex<...>>, Rust's standard pattern for shared mutable state:

// conversation.rs - shared across all handlers
pub type SharedConversation = Arc<Mutex<Vec<Message>>>;

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct Message {
    pub role: String,    // "user" or "assistant"
    pub content: String,
}

The Arc makes the conversation cloneable across Axum handlers (each handler runs in its own async task), and the Mutex ensures only one handler touches the history at a time. No race conditions, guaranteed by the type system.

Dual-Mode: Web UI + CLI

The app launches in Web UI mode by default, but also supports a terminal workflow:

# Default: serves Web UI at http://localhost:8080
cargo run

# CLI mode: interactive terminal chat
cargo run -- cli

# Explicit web mode on a custom port
PORT=3000 cargo run -- web

This is useful in different contexts — the Web UI for demos and sharing, the CLI for scripting and piping into other tools.

Quick Start

Option A: No Rust Required

Download the prebuilt Windows executable (v1.0.1) and run it:

.\chatbot.exe
# Opens http://localhost:8080

Option B: From Source

# 1. Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# 2. Clone and configure
git clone https://github.com/MihirMohapatra/chatbot.git
cd chatbot
cp .env.example .env

# 3. Run
cargo run

Provider Configuration

Set your provider in .env:

Claude (Anthropic)

PROVIDER=claude
ANTHROPIC_API_KEY=sk-ant-...

OpenAI

PROVIDER=openai
OPENAI_API_KEY=sk-...

Ollama (Local — no API key needed)

# Pull a model first
ollama pull llama3.2

PROVIDER=ollama
MODEL=llama3.2

OpenRouter (access any model via OpenAI-compatible API)

PROVIDER=openai
OPENAI_API_KEY=sk-or-...
BASE_URL=https://openrouter.ai/api
MODEL=anthropic/claude-sonnet-4

All environment variables:

Variable	Default	Description
`PROVIDER`	`claude`	`claude`, `openai`, `ollama`
`ANTHROPIC_API_KEY`	—	Required for Claude
`OPENAI_API_KEY`	—	Required for OpenAI
`MODEL`	provider default	Override the model name
`BASE_URL`	provider default	Override the API endpoint
`MAX_TOKENS`	`1024`	Response token cap
`SYSTEM_PROMPT`	built-in	Custom assistant behavior

Docker

docker build -t chatbot .
docker run -it --rm -v .env:/data/.env chatbot

For Ollama with host networking:

docker run -it --rm --network host -v .env:/data/.env chatbot

Rust vs Python: Backend Performance Perspective

For backend workloads like this (concurrent HTTP + JSON + state management), Rust consistently outperforms Python across the metrics that matter in production:

Metric	Rust	Python	Why It Matters
Throughput (req/sec)	Higher	Lower	More concurrent users per instance
P95/P99 latency	Lower under load	Higher under load	More stable response times
Memory per worker	Lower	Higher	Better infra cost and density
CPU efficiency	Higher	Lower	More headroom before scaling out

Note: For LLM apps, model/API network time dominates total latency. But Rust still wins on concurrency behavior, memory footprint, and server efficiency — which directly impacts cost and reliability at scale.

What's Next (Roadmap)

Streamed responses — token-by-token streaming via SSE
Persistent chat history — SQLite or Postgres backend
Metrics + tracing — tracing crate + OpenTelemetry integration
Integration tests for provider adapters

Try It / Contribute

The project is open source and MIT licensed:

👉 github.com/MihirMohapatra/chatbot

If you're exploring Rust for backend systems, or building something that needs to talk to multiple AI providers without writing boilerplate for each one, this is a good starting point. Issues and PRs welcome.

Built with Rust 1.80+, Tokio, Axum, reqwest, serde, and anyhow.

Rust Concepts: Serde, Error Handling, Benchmarking & Workspaces (Part 6)

mihir mohapatra — Mon, 25 May 2026 06:16:23 +0000

This is Part 6 — the final part of the Core Rust Concepts series.

Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching

Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await

Part 3 — Macros, Modules, Testing, Unsafe Rust, FFI

Part 4 — Threads, Channels, Send/Sync, Mutex, Atomics, clap

Part 5 — dyn Trait, Deref, Drop, Custom Iterators, Axum REST API

Serde — Serialization Deep Dive
Error Handling with thiserror and anyhow
Benchmarking with Criterion
Workspaces & Multi-Crate Projects
Writing a Real-World CLI + Library Crate

30. Serde — Serialization Deep Dive

serde is Rust's de-facto serialization framework. It supports JSON, TOML, YAML, MessagePack, Bincode, and dozens of other formats — all from the same #[derive] annotations.

Setup

[dependencies]
serde       = { version = "1", features = ["derive"] }
serde_json  = "1"
toml        = "0.8"

Basic serialize / deserialize

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct User {
    id: u32,
    name: String,
    email: String,
    active: bool,
}

fn main() {
    let user = User {
        id: 1,
        name: String::from("Alice"),
        email: String::from("alice@example.com"),
        active: true,
    };

    // Struct → JSON string
    let json = serde_json::to_string_pretty(&user).unwrap();
    println!("{json}");

    // JSON string → Struct
    let json_str = r#"{"id":2,"name":"Bob","email":"bob@example.com","active":false}"#;
    let parsed: User = serde_json::from_str(json_str).unwrap();
    println!("{:?}", parsed);
}

Output:

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "active": true
}

Field attributes

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Article {
    #[serde(rename = "article_id")]
    id: u32,

    title: String,

    #[serde(skip_serializing_if = "Option::is_none")]
    subtitle: Option<String>,

    #[serde(default)]
    published: bool,

    #[serde(skip)]
    internal_notes: String, // never included in JSON

    #[serde(rename = "created_at")]
    created: String,
}

fn main() {
    let article = Article {
        id: 42,
        title: String::from("Learning Rust"),
        subtitle: None,             // skipped in output
        published: true,
        internal_notes: String::from("draft"), // skipped
        created: String::from("2026-01-01"),
    };

    println!("{}", serde_json::to_string_pretty(&article).unwrap());
}

Output:

{
  "article_id": 42,
  "title": "Learning Rust",
  "published": true,
  "created_at": "2026-01-01"
}

Enums with serde

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
#[serde(tag = "type", content = "data")]
enum Event {
    UserCreated { user_id: u32, name: String },
    OrderPlaced { order_id: u32, total: f64 },
    PageViewed(String),
}

fn main() {
    let events = vec![
        Event::UserCreated { user_id: 1, name: String::from("Alice") },
        Event::OrderPlaced { order_id: 99, total: 49.95 },
        Event::PageViewed(String::from("/home")),
    ];

    for e in &events {
        println!("{}", serde_json::to_string(e).unwrap());
    }
}

Output:

{"type":"UserCreated","data":{"user_id":1,"name":"Alice"}}
{"type":"OrderPlaced","data":{"order_id":99,"total":49.95}}
{"type":"PageViewed","data":"/home"}

Custom serialize / deserialize

use serde::{Deserialize, Deserializer, Serialize, Serializer};

#[derive(Debug)]
struct Rgb(u8, u8, u8);

impl Serialize for Rgb {
    fn serialize<S: Serializer>(&self, s: S) -> Result<S::Ok, S::Error> {
        s.serialize_str(&format!("#{:02X}{:02X}{:02X}", self.0, self.1, self.2))
    }
}

impl<'de> Deserialize<'de> for Rgb {
    fn deserialize<D: Deserializer<'de>>(d: D) -> Result<Self, D::Error> {
        let s = String::deserialize(d)?;
        let hex = s.trim_start_matches('#');
        let r = u8::from_str_radix(&hex[0..2], 16).map_err(serde::de::Error::custom)?;
        let g = u8::from_str_radix(&hex[2..4], 16).map_err(serde::de::Error::custom)?;
        let b = u8::from_str_radix(&hex[4..6], 16).map_err(serde::de::Error::custom)?;
        Ok(Rgb(r, g, b))
    }
}

fn main() {
    let color = Rgb(255, 128, 0);
    let json = serde_json::to_string(&color).unwrap();
    println!("{json}"); // "#FF8000"

    let back: Rgb = serde_json::from_str(&json).unwrap();
    println!("{:?}", back); // Rgb(255, 128, 0)
}

Working with dynamic JSON (`serde_json::Value`)

use serde_json::{json, Value};

fn main() {
    // Build JSON with the json! macro
    let payload = json!({
        "name": "Alice",
        "scores": [98, 87, 95],
        "meta": { "verified": true }
    });

    // Navigate dynamically
    println!("{}", payload["name"]);             // "Alice"
    println!("{}", payload["scores"][0]);         // 98
    println!("{}", payload["meta"]["verified"]);  // true

    // Merge two JSON objects
    let mut base: Value = json!({ "a": 1, "b": 2 });
    let extra: Value    = json!({ "b": 99, "c": 3 });

    if let (Value::Object(base_map), Value::Object(extra_map)) = (&mut base, extra) {
        base_map.extend(extra_map);
    }

    println!("{}", serde_json::to_string_pretty(&base).unwrap());
    // { "a": 1, "b": 99, "c": 3 }
}

31. Error Handling with thiserror and anyhow

Rust's Result<T, E> is powerful but verbose when you have many error types. Two crates solve this cleanly — thiserror for library authors, anyhow for application code.

[dependencies]
thiserror = "1"
anyhow    = "1"

thiserror — define your own error types

use thiserror::Error;

#[derive(Debug, Error)]
enum AppError {
    #[error("user not found: id={0}")]
    UserNotFound(u32),

    #[error("database error: {0}")]
    Database(#[from] std::io::Error),

    #[error("invalid email: {email}")]
    InvalidEmail { email: String },

    #[error("permission denied for user {user_id} on resource {resource}")]
    PermissionDenied { user_id: u32, resource: String },
}

fn find_user(id: u32) -> Result<String, AppError> {
    if id == 0 {
        return Err(AppError::UserNotFound(id));
    }
    Ok(format!("user_{id}"))
}

fn validate_email(email: &str) -> Result<(), AppError> {
    if !email.contains('@') {
        return Err(AppError::InvalidEmail { email: email.to_string() });
    }
    Ok(())
}

fn main() {
    match find_user(0) {
        Ok(u)  => println!("found: {u}"),
        Err(e) => println!("error: {e}"), // "error: user not found: id=0"
    }

    if let Err(e) = validate_email("notanemail") {
        println!("{e}"); // "invalid email: notanemail"
    }
}

anyhow — ergonomic error handling in applications

use anyhow::{anyhow, bail, Context, Result};
use std::fs;

fn read_config(path: &str) -> Result<String> {
    let content = fs::read_to_string(path)
        .with_context(|| format!("failed to read config from '{path}'"))?;

    if content.is_empty() {
        bail!("config file '{path}' is empty");
    }

    Ok(content)
}

fn parse_port(s: &str) -> Result<u16> {
    s.parse::<u16>()
        .map_err(|_| anyhow!("'{}' is not a valid port number (0–65535)", s))
}

fn main() -> Result<()> {
    // anyhow::Result as the return type of main — shows a clean error message
    let config = read_config("config.toml")
        .context("startup failed")?;

    println!("config loaded: {} bytes", config.len());

    let port = parse_port("8080")?;
    println!("listening on port {port}");

    Ok(())
}

thiserror vs anyhow — when to use which

	`thiserror`	`anyhow`
Best for	Libraries	Applications / binaries
Error type	Typed, structured `enum`	Opaque `anyhow::Error`
Callers can match on variants	✅	❌
Context chaining	Manual	`.context()` built-in
Boilerplate	Low	Minimal

Combining both

// In your library: typed errors with thiserror
#[derive(Debug, thiserror::Error)]
pub enum DbError {
    #[error("connection failed: {0}")]
    Connection(String),
    #[error("query failed: {0}")]
    Query(String),
}

// In your binary: use anyhow to wrap everything
fn run() -> anyhow::Result<()> {
    let result: Result<(), DbError> = Err(DbError::Connection("timeout".into()));
    result?; // DbError converts into anyhow::Error automatically
    Ok(())
}

32. Benchmarking with Criterion

criterion is the standard Rust benchmarking library. It runs each benchmark many times, measures variance, detects regressions, and generates HTML reports.

[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name    = "my_benchmark"
harness = false

Basic benchmark

// benches/my_benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 => 0,
        1 => 1,
        n => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn fibonacci_iter(n: u64) -> u64 {
    let (mut a, mut b) = (0u64, 1u64);
    for _ in 0..n { (a, b) = (b, a + b); }
    a
}

fn bench_fibonacci(c: &mut Criterion) {
    let mut group = c.benchmark_group("fibonacci");

    group.bench_function("recursive n=20", |b| {
        b.iter(|| fibonacci(black_box(20)))
    });

    group.bench_function("iterative n=20", |b| {
        b.iter(|| fibonacci_iter(black_box(20)))
    });

    group.finish();
}

criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);

cargo bench

Sample output:

fibonacci/recursive n=20  time: [123.45 µs 124.12 µs 124.89 µs]
fibonacci/iterative n=20  time: [  1.23 ns   1.24 ns   1.25 ns]

Performance has improved: iterative is 100000x faster.

Benchmarking with input sizes

use criterion::{black_box, criterion_group, criterion_main, BenchmarkId, Criterion};

fn sum_vec(v: &[i32]) -> i32 { v.iter().sum() }

fn bench_sum(c: &mut Criterion) {
    let mut group = c.benchmark_group("vec_sum");

    for size in [100, 1_000, 10_000, 100_000] {
        let data: Vec<i32> = (0..size).collect();

        group.bench_with_input(
            BenchmarkId::new("sum", size),
            &data,
            |b, v| b.iter(|| sum_vec(black_box(v))),
        );
    }

    group.finish();
}

criterion_group!(benches, bench_sum);
criterion_main!(benches);

What `black_box` does

black_box(x) prevents the compiler from optimizing away the computation. Without it, the compiler might realize the result is unused and eliminate the benchmark entirely, giving you falsely fast timings.

// ❌ Compiler may optimize this to nothing
b.iter(|| fibonacci(20));

// ✅ Forces the computation to actually run
b.iter(|| fibonacci(black_box(20)));

33. Workspaces & Multi-Crate Projects

As projects grow, you split them into multiple crates in a Cargo workspace. All crates share one Cargo.lock and one target/ directory — so they share compiled dependencies and build faster.

Workspace layout

my_project/
├── Cargo.toml          ← workspace root
├── crates/
│   ├── core/           ← shared library
│   │   ├── Cargo.toml
│   │   └── src/
│   │       └── lib.rs
│   ├── cli/            ← binary using core
│   │   ├── Cargo.toml
│   │   └── src/
│   │       └── main.rs
│   └── api/            ← web server using core
│       ├── Cargo.toml
│       └── src/
│           └── main.rs

Root Cargo.toml

# Cargo.toml (workspace root)
[workspace]
members = [
    "crates/core",
    "crates/cli",
    "crates/api",
]
resolver = "2"

# Shared dependency versions across all crates
[workspace.dependencies]
serde     = { version = "1", features = ["derive"] }
tokio     = { version = "1", features = ["full"] }
anyhow    = "1"
thiserror = "1"

core/Cargo.toml

[package]
name    = "core"
version = "0.1.0"
edition = "2021"

[dependencies]
serde     = { workspace = true }
thiserror = { workspace = true }

cli/Cargo.toml

[package]
name    = "cli"
version = "0.1.0"
edition = "2021"

[dependencies]
core   = { path = "../core" }
anyhow = { workspace = true }
clap   = { version = "4", features = ["derive"] }

Sharing types across crates

// crates/core/src/lib.rs
use serde::{Deserialize, Serialize};
use thiserror::Error;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct User {
    pub id: u32,
    pub name: String,
    pub email: String,
}

#[derive(Debug, Error)]
pub enum CoreError {
    #[error("user not found: {0}")]
    NotFound(u32),
    #[error("invalid input: {0}")]
    InvalidInput(String),
}

pub fn find_user(id: u32) -> Result<User, CoreError> {
    if id == 0 {
        return Err(CoreError::NotFound(id));
    }
    Ok(User { id, name: format!("user_{id}"), email: format!("user{id}@example.com") })
}

// crates/cli/src/main.rs
use clap::Parser;
use core::{find_user, CoreError};

#[derive(Parser)]
struct Cli {
    #[arg(short, long)]
    id: u32,
}

fn main() {
    let cli = Cli::parse();
    match find_user(cli.id) {
        Ok(user)  => println!("Found: {} <{}>", user.name, user.email),
        Err(CoreError::NotFound(id)) => eprintln!("No user with id {id}"),
        Err(e)    => eprintln!("Error: {e}"),
    }
}

Useful workspace commands

# Build all crates
cargo build --workspace

# Test all crates
cargo test --workspace

# Run a specific crate's binary
cargo run -p cli -- --id 42

# Check all without building
cargo check --workspace

# Lint everything
cargo clippy --workspace

# Format everything
cargo fmt --all

34. Writing a Real-World CLI + Library Crate

Putting it all together — a filestat tool that analyzes text files and exposes its logic as a reusable library.

Library: `crates/filestat-core/src/lib.rs`

use serde::Serialize;
use std::collections::HashMap;
use thiserror::Error;

#[derive(Debug, Error)]
pub enum StatError {
    #[error("could not read file '{path}': {source}")]
    Io { path: String, #[source] source: std::io::Error },
    #[error("file '{0}' is empty")]
    Empty(String),
}

#[derive(Debug, Serialize)]
pub struct FileStats {
    pub path: String,
    pub lines: usize,
    pub words: usize,
    pub chars: usize,
    pub unique_words: usize,
    pub top_words: Vec<(String, usize)>,
}

pub fn analyze(path: &str) -> Result<FileStats, StatError> {
    let content = std::fs::read_to_string(path)
        .map_err(|e| StatError::Io { path: path.to_string(), source: e })?;

    if content.trim().is_empty() {
        return Err(StatError::Empty(path.to_string()));
    }

    let lines = content.lines().count();
    let chars = content.chars().count();

    let words: Vec<&str> = content
        .split_whitespace()
        .collect();

    let word_count = words.len();

    let mut freq: HashMap<String, usize> = HashMap::new();
    for word in &words {
        let clean = word.to_lowercase()
            .trim_matches(|c: char| !c.is_alphanumeric())
            .to_string();
        if !clean.is_empty() {
            *freq.entry(clean).or_insert(0) += 1;
        }
    }

    let unique_words = freq.len();

    let mut top_words: Vec<(String, usize)> = freq.into_iter().collect();
    top_words.sort_by(|a, b| b.1.cmp(&a.1));
    top_words.truncate(5);

    Ok(FileStats {
        path: path.to_string(),
        lines,
        words: word_count,
        chars,
        unique_words,
        top_words,
    })
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_basic_stats() {
        use std::io::Write;
        let mut f = tempfile::NamedTempFile::new().unwrap();
        writeln!(f, "hello world hello rust world world").unwrap();
        let stats = analyze(f.path().to_str().unwrap()).unwrap();
        assert_eq!(stats.lines, 1);
        assert_eq!(stats.words, 6);
        assert_eq!(stats.unique_words, 3);
        assert_eq!(stats.top_words[0].0, "world");
        assert_eq!(stats.top_words[0].1, 3);
    }
}

CLI: `crates/filestat-cli/src/main.rs`

use anyhow::{Context, Result};
use clap::{Parser, ValueEnum};
use filestat_core::{analyze, StatError};

#[derive(ValueEnum, Clone, Debug)]
enum OutputFormat {
    Text,
    Json,
}

#[derive(Parser)]
#[command(name = "filestat", about = "Analyze text file statistics")]
struct Cli {
    /// Files to analyze
    files: Vec<String>,

    /// Output format
    #[arg(short, long, value_enum, default_value = "text")]
    format: OutputFormat,

    /// Show top N words (default: 5)
    #[arg(long, default_value_t = 5)]
    top: usize,
}

fn main() -> Result<()> {
    let cli = Cli::parse();

    if cli.files.is_empty() {
        anyhow::bail!("no files provided. Use: filestat <file1> [file2 ...]");
    }

    for path in &cli.files {
        match analyze(path) {
            Ok(stats) => match cli.format {
                OutputFormat::Json => {
                    println!("{}", serde_json::to_string_pretty(&stats)
                        .context("failed to serialize stats")?);
                }
                OutputFormat::Text => {
                    println!("── {} ──", stats.path);
                    println!("  Lines:        {}", stats.lines);
                    println!("  Words:        {}", stats.words);
                    println!("  Characters:   {}", stats.chars);
                    println!("  Unique words: {}", stats.unique_words);
                    println!("  Top {} words:", cli.top);
                    for (word, count) in stats.top_words.iter().take(cli.top) {
                        println!("    {:20} {}", word, count);
                    }
                }
            },
            Err(StatError::Empty(p)) => eprintln!("skipping '{p}': file is empty"),
            Err(e) => eprintln!("error: {e}"),
        }
    }

    Ok(())
}

Running it:

$ cargo run -p filestat-cli -- README.md --format text
── README.md ──
  Lines:        42
  Words:        381
  Characters:   2104
  Unique words: 198
  Top 5 words:
    the                  24
    rust                 18
    and                  15
    a                    12
    to                   11

$ cargo run -p filestat-cli -- README.md --format json
{
  "path": "README.md",
  "lines": 42,
  "words": 381,
  ...
}

Wrapping Up Part 6

Concept	What it gives you
serde	Zero-boilerplate serialization to any format
thiserror	Typed, ergonomic library error enums
anyhow	Context-rich error propagation in apps
criterion	Statistical, regression-detecting benchmarks
Workspaces	Multi-crate projects with shared dependencies
CLI + Library	Separation of logic and interface, reusable core

The Complete Series

Part	Topics
Part 1	Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching
Part 2	Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await
Part 3	Macros, Modules, Cargo, Testing, Unsafe, FFI
Part 4	Threads, Channels, Send/Sync, Mutex, Atomics, clap
Part 5	dyn Trait, Deref, Drop, Custom Iterators, Axum REST API
Part 6	Serde, thiserror, anyhow, Criterion, Workspaces, CLI + Library

Where to Go Next

You've covered the full breadth of Rust — here's what to explore next:

The Rust Book — the official, free, comprehensive reference
Rustlings — hands-on exercises
Rust by Example — example-driven learning
Jon Gjengset on YouTube — deep dives into advanced Rust
Blessed.rs — curated list of recommended crates
This Week in Rust — weekly newsletter

Thanks for following the entire series! If it helped you, drop a ❤️ on each part and share with someone learning Rust. See you in the next one! 🦀

Building a Real-Time Collaborative Task Board: How Gemini Helped Me Build for the Google I/O Challenge 2026 🚀

mihir mohapatra — Sat, 23 May 2026 20:20:23 +0000

🚀 Google I/O Challenge 2026: Collaborative Task Board

Managing workflows in modern remote-first teams demands highly fluid, non-blocking digital hubs. For the Google I/O Challenge 2026, I wanted to design and build a Collaborative Task Board that replicates the rich interactive experiences of industry-standard visual workspaces—built in record time under the guidance of Google Gemini in AI Studio.

🔗 Try the Live App Here: Collaborative Task Board Live Link

(Tip: Open the URL in two separate windows or share it with a teammate to watch cursors sync live!)

🎨 Creative Vision & Application Features

The Collaborative Task Board is designed on top of a comfortable, premium, high-contrast Slate Indigo theme utilizing precise typography pairs: Space Grotesk display headings alongside JetBrains Mono for live status elements.

Key Capabilities Included:

👥 Real-Time User Presence: Teammates onboard instantly with customized nicknames and color identity themes, forming an active avatar stack representing who is inside the room.
🖱️ Adaptive Cursor Trails: Witness low-latency mouse tracking broadcasts complete with custom colors and labels matching each coworker's cursor.
🔒 Intelligent Focus Locks (Anti-Collision): If a teammate is editing cards, configuring properties, or appending discussions, the card is locked system-wide with a glowing visual banner to prevent editing collisions.
📦 Express-WebSocket State Machine: High-performance socket pipelines sync all structural change actions—creation, descriptions, priority shifts, comment additions, and drag motions—globally.
💬 Integrated Chat Forums: Each room coordinates an isolated workspace chat to talk in real-time alongside Kanban columns.
🔑 Dynamic Room Routing: Simply change the ?room= link query or inputs to create isolated spaces for separate teams.

🤖 Co-Architecting with Gemini on AI Studio

Building a truly real-time interactive coordinate tracking space is notoriously tricky to scale and refine. Gemini acted as a world-class senior developer, helper, and designer at every stage:

Architecture Design: Gemini drafted the structured type interfaces and strict client/server communication state schemas, ensuring that backend events maps to the unified source of truth.
WebSocket Integration: Gemini successfully avoided the classic React WebSocket footprint trap (re-instantiating connections on state changes) by leveraging persistent useRef handlers, combining robust fallback backoff reconnection logic.
Performance Optimization: To keep cursor broadcast packets lightweight, Gemini suggested a 45ms throttle on pointer updates, reducing websocket server load by up to 80% while maintaining premium human-eye fluidity.
No Mock Infrastructure: Guided by AI Studio's architectural guidelines, Gemini crafted a real Node/Express backend on disk instead of simple mockup timeouts, giving us live server and client synchronizations dynamically served on Cloud Run.

🛠️ Tech Stack & Implementation Details

Frontend: React 19, Tailwind CSS, Lucide icons, and motion (Framer) for fluid task rearrangements.
Backend: Node.js/TypeScript running an Express server bound with robust memory states, hosted on Google's scalable Cloud Run container environment.
Persistence & Sync: Raw ws WebSocket servers combined with robust JSON snapshots saved automatically to local data volumes matching active operations.

💭 Reflection & Google I/O Appreciation

Developing this project using AI Studio Build has been an incredible experience. The ability to express intent naturally and immediately receive clean TypeScript modules, matching proper bundler builds and actual socket integrations, makes it incredibly fun to take products from simple sketches to live, ready-to-test systems.

Let me know what you think by jumping into my collaborative workspace room! Let's build together. 🤖

Built with ♥ for the Google I/O Challenge 2026.

First Look: Building the Agentic Future with Gemini 3.5 Flash and Antigravity 2.0

mihir mohapatra — Sat, 23 May 2026 19:06:40 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 marked a permanent shift in how we build software. We are officially moving past the era of raw prompt engineering and entering the domain of autonomous, agentic action.

During the developer keynotes, Google introduced Gemini 3.5 Flash—a low-latency engine running four times faster than previous models—alongside Google Antigravity 2.0, an infrastructure tool designed to lift the operational weight of orchestrating multi-agent workflows off development teams.

Here is a practical, first-look guide on how these two primitives work together to change your development lifecycle.

The Core Primitives

To build an application that does things rather than just generating text, you need two things: high-velocity model execution and a predictable runtime framework.

Feature / Primitive	Gemini 3.5 Flash	Google Antigravity 2.0
Primary Role	High-speed multi-modal reasoning engine	Agent orchestration and predictive scaling framework
Performance	4x faster execution than previous frontier models	Prevents cold-start latencies during 40x traffic surges
Interface	Gemini API & Native Google AI Studio Integration	Standalone Desktop App, CLI, and Programmatic SDK

1. Zero-Friction Orchestration with Antigravity 2.0

Orchestrating multiple asynchronous developer tasks usually requires a chaotic mess of polling mechanisms, state databases, and custom queues. The Antigravity CLI unifies these terminal tasks into a fast, Go-based experience that completely replaces the legacy Gemini CLI.

# Install the new Antigravity CLI
npm install -g @google/antigravity-cli

# Initialize a multi-agent project workspace
antigravity init agent-workspace

The runtime lets you invoke Managed Agents inside the Gemini API. These agents run inside a private Linux sandbox, allowing them to write code, call APIs, and execute functions natively without exposing your local environment.

2. Speed Run: From Prompt to Play Store

Google AI Studio now handles native Android support, meaning you can vibe-code an application using recommended patterns (like Jetpack Compose and Kotlin) and deploy it straight to an emulator.

// Example: A clean, agentic UI layout generated natively with Jetpack Compose
@Composable
fun AgentStatusScreen(modifier: Modifier = Modifier) {
    Column(
        modifier = modifier.fillMaxSize().padding(16.dp),
        verticalArrangement = Arrangement.Center
    ) {
        Text(
            text = "Agent Status: Executing Task...",
            style = MaterialTheme.typography.headlineMedium
        )
        LinearProgressIndicator(modifier = Modifier.fillMaxWidth())
    }
}

Once your agent builds and iterates on the code, you can export your local development context to production with a single click or pipeline it straight to the Google Play Console internal test track.

3. The New Protocol: Agent2Agent (A2A)

For builders focusing on cross-app automation, Google introduced the Agent2Agent (A2A) Protocol. Instead of polling an API to check if a long-running background task is finished, the A2A protocol uses Server-Sent Events (SSE) to push progress updates natively.

// Listening to a long-running background code execution via A2A
const eventSource = new EventSource('https://google.com');

eventSource.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log(`Agent execution progress: ${data.progress}%`);
    if (data.status === 'COMPLETED') {
        eventSource.close();
    }
};

Verdict for Builders

I/O 2026 wasn't a conference built on vaporware; it delivered developer infrastructure. By providing a 2-million-token context window that can digest an entire codebase alongside automated frameworks like Antigravity, Google has effectively made the underlying AI infrastructure disappear.

If you are looking to test your skills with these new primitives, registration is officially open for the Build with Gemini XPRIZE Hackathon, featuring a $2 million prize pool.

References

Catch up on the technical summaries via the official Google Developer Blog.
Dive into model specifications on the Google AI Developer Platform.

Rust Concepts: dyn Trait, Custom Iterators, Deref/Drop & Axum REST API (Part 5)

mihir mohapatra — Fri, 22 May 2026 07:21:24 +0000

This is Part 5 of the Core Rust Concepts series.

Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching

Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await

Part 3 — Macros, Modules, Testing, Unsafe Rust, FFI

Part 4 — Threads, Channels, Send/Sync, Mutex, Atomics, clap

Trait Objects and Dynamic Dispatch
The Deref Trait
The Drop Trait
Custom Iterators
Building a REST API with Axum

25. Trait Objects and Dynamic Dispatch

In Part 2 we used impl Trait — that's static dispatch: the compiler knows the exact type at compile time and monomorphizes it. Sometimes you don't know the type until runtime. That's where trait objects (dyn Trait) come in.

Static vs Dynamic dispatch

trait Greet {
    fn hello(&self) -> String;
}

struct English;
struct Spanish;

impl Greet for English {
    fn hello(&self) -> String { String::from("Hello!") }
}

impl Greet for Spanish {
    fn hello(&self) -> String { String::from("¡Hola!") }
}

// Static dispatch — type known at compile time, zero overhead
fn greet_static(g: &impl Greet) {
    println!("{}", g.hello());
}

// Dynamic dispatch — type known at runtime via vtable
fn greet_dynamic(g: &dyn Greet) {
    println!("{}", g.hello());
}

fn main() {
    let e = English;
    let s = Spanish;

    greet_static(&e);
    greet_dynamic(&s);

    // Only dyn Trait allows mixing types in a collection
    let greeters: Vec<Box<dyn Greet>> = vec![
        Box::new(English),
        Box::new(Spanish),
        Box::new(English),
    ];

    for g in &greeters {
        println!("{}", g.hello());
    }
}

When to use `dyn Trait` vs `impl Trait`

	`impl Trait`	`dyn Trait`
Dispatch	Static (compile time)	Dynamic (runtime vtable)
Performance	Zero overhead	Small indirection cost
Heterogeneous collections	❌	✅
Return from function	✅ (one concrete type)	✅ (any type at runtime)
Sized	✅	❌ (must be behind `&` or `Box`)

Object-safe traits

Not every trait can be made into a trait object. A trait is object-safe if:

It has no methods that return Self
It has no generic methods

// ✅ Object-safe
trait Drawable {
    fn draw(&self);
    fn area(&self) -> f64;
}

// ❌ NOT object-safe — returns Self
trait Clone2 {
    fn clone2(&self) -> Self; // can't use as dyn Clone2
}

Real-world pattern — plugin system

trait Plugin {
    fn name(&self) -> &str;
    fn run(&self, input: &str) -> String;
}

struct UppercasePlugin;
struct ReversePlugin;

impl Plugin for UppercasePlugin {
    fn name(&self) -> &str { "uppercase" }
    fn run(&self, input: &str) -> String { input.to_uppercase() }
}

impl Plugin for ReversePlugin {
    fn name(&self) -> &str { "reverse" }
    fn run(&self, input: &str) -> String { input.chars().rev().collect() }
}

struct Pipeline {
    plugins: Vec<Box<dyn Plugin>>,
}

impl Pipeline {
    fn new() -> Self { Self { plugins: vec![] } }

    fn add(mut self, p: Box<dyn Plugin>) -> Self {
        self.plugins.push(p);
        self
    }

    fn run(&self, input: &str) -> String {
        self.plugins.iter().fold(input.to_string(), |acc, p| p.run(&acc))
    }
}

fn main() {
    let pipeline = Pipeline::new()
        .add(Box::new(UppercasePlugin))
        .add(Box::new(ReversePlugin));

    println!("{}", pipeline.run("hello")); // "OLLEH"
}

26. The Deref Trait

Deref controls what happens when you use the * operator on a type. It's also what enables deref coercions — Rust automatically calls deref() to convert types so you don't have to do it manually.

use std::ops::Deref;

// A simple smart pointer
struct MyBox<T>(T);

impl<T> MyBox<T> {
    fn new(x: T) -> MyBox<T> { MyBox(x) }
}

impl<T> Deref for MyBox<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.0 // return a reference to the inner value
    }
}

fn hello(name: &str) {
    println!("Hello, {name}!");
}

fn main() {
    let x = MyBox::new(String::from("Rustacean"));

    // These are all equivalent due to deref coercions:
    hello(&x);           // MyBox<String> → &String → &str  (auto!)
    hello(&(*x)[..]);    // manual — what Rust does behind the scenes
    hello(x.deref());    // explicit deref
}

Deref coercion chain

Rust automatically chains Deref calls as many times as needed:

MyBox<String>  →  String  →  str
    &MyBox<String>  →  &String  →  &str

fn main() {
    let boxed = Box::new(String::from("hello"));

    // Box<String> derefs to String, then to str
    println!("{}", boxed.to_uppercase()); // HELLO
    println!("{}", boxed.len());          // 5

    let s: &str = &boxed; // Box<String> → &String → &str — all automatic
    println!("{s}");
}

DerefMut

DerefMut does the same for mutable contexts:

use std::ops::{Deref, DerefMut};

struct Wrapper(Vec<i32>);

impl Deref for Wrapper {
    type Target = Vec<i32>;
    fn deref(&self) -> &Vec<i32> { &self.0 }
}

impl DerefMut for Wrapper {
    fn deref_mut(&mut self) -> &mut Vec<i32> { &mut self.0 }
}

fn main() {
    let mut w = Wrapper(vec![1, 2, 3]);
    w.push(4);                     // DerefMut lets you call Vec methods
    println!("{:?}", w.as_slice()); // Deref: [1, 2, 3, 4]
}

27. The Drop Trait

Drop lets you run custom cleanup code when a value goes out of scope — like a destructor in C++. Rust calls drop() automatically; you never call it yourself (use std::mem::drop() to drop early).

struct Resource {
    name: String,
}

impl Resource {
    fn new(name: &str) -> Self {
        println!("acquiring: {name}");
        Resource { name: name.to_string() }
    }
}

impl Drop for Resource {
    fn drop(&mut self) {
        println!("releasing: {}", self.name);
    }
}

fn main() {
    let _a = Resource::new("database connection");
    let _b = Resource::new("file handle");
    println!("resources in use...");
    // Drop order is LIFO: _b dropped first, then _a
}

Output:

acquiring: database connection
acquiring: file handle
resources in use...
releasing: file handle
releasing: database connection

Dropping early

fn main() {
    let conn = Resource::new("db");
    println!("doing work...");

    drop(conn); // explicit early drop — calls Drop::drop()
    println!("conn already released");

    // conn.name; ← compile error: value was dropped
}

Drop in practice — RAII pattern

use std::sync::{Arc, Mutex};

struct DbPool {
    connections: Arc<Mutex<Vec<String>>>,
}

struct DbConnection {
    id: String,
    pool: Arc<Mutex<Vec<String>>>,
}

impl Drop for DbConnection {
    fn drop(&mut self) {
        // Return the connection back to the pool automatically
        self.pool.lock().unwrap().push(self.id.clone());
        println!("connection '{}' returned to pool", self.id);
    }
}

impl DbPool {
    fn new() -> Self {
        let conns = vec!["conn-1".into(), "conn-2".into(), "conn-3".into()];
        Self { connections: Arc::new(Mutex::new(conns)) }
    }

    fn get(&self) -> Option<DbConnection> {
        let id = self.connections.lock().unwrap().pop()?;
        println!("checked out: {id}");
        Some(DbConnection { id, pool: Arc::clone(&self.connections) })
    }
}

fn main() {
    let pool = DbPool::new();
    {
        let _c1 = pool.get(); // "conn-3"
        let _c2 = pool.get(); // "conn-2"
    } // both returned to pool here automatically
    println!("pool size: {}", pool.connections.lock().unwrap().len()); // 3
}

🦀 This is the RAII (Resource Acquisition Is Initialization) pattern — the same one Rust's MutexGuard, file handles, and socket wrappers use internally.

28. Custom Iterators

You can make any type iterable by implementing the Iterator trait, which requires only one method: next().

struct Counter {
    count: u32,
    max: u32,
}

impl Counter {
    fn new(max: u32) -> Self { Self { count: 0, max } }
}

impl Iterator for Counter {
    type Item = u32;

    fn next(&mut self) -> Option<Self::Item> {
        if self.count < self.max {
            self.count += 1;
            Some(self.count)
        } else {
            None // signals the iterator is exhausted
        }
    }
}

fn main() {
    let counter = Counter::new(5);

    // You get ALL iterator methods for free!
    let sum: u32 = counter.sum();
    println!("sum: {sum}"); // 15

    // Chain with other iterators
    let result: Vec<u32> = Counter::new(5)
        .zip(Counter::new(5).skip(1))   // pair consecutive values
        .map(|(a, b)| a * b)            // multiply each pair
        .filter(|x| x % 3 == 0)        // keep multiples of 3
        .collect();

    println!("{:?}", result); // [6, 12]
}

A real-world custom iterator — paginated results

struct Paginator {
    current_page: u32,
    total_pages: u32,
    page_size: u32,
}

impl Paginator {
    fn new(total_items: u32, page_size: u32) -> Self {
        Self {
            current_page: 0,
            total_pages: (total_items + page_size - 1) / page_size,
            page_size,
        }
    }
}

#[derive(Debug)]
struct Page {
    number: u32,
    offset: u32,
    limit: u32,
}

impl Iterator for Paginator {
    type Item = Page;

    fn next(&mut self) -> Option<Page> {
        if self.current_page < self.total_pages {
            self.current_page += 1;
            Some(Page {
                number: self.current_page,
                offset: (self.current_page - 1) * self.page_size,
                limit: self.page_size,
            })
        } else {
            None
        }
    }
}

fn main() {
    let pages = Paginator::new(95, 20);

    for page in pages {
        println!("Page {}: OFFSET {} LIMIT {}", page.number, page.offset, page.limit);
    }
}

Output:

Page 1: OFFSET 0 LIMIT 20
Page 2: OFFSET 20 LIMIT 20
Page 3: OFFSET 40 LIMIT 20
Page 4: OFFSET 60 LIMIT 20
Page 5: OFFSET 80 LIMIT 20

IntoIterator — making structs work in for loops

struct Stack<T> {
    items: Vec<T>,
}

impl<T> Stack<T> {
    fn new() -> Self { Self { items: vec![] } }
    fn push(&mut self, item: T) { self.items.push(item); }
}

impl<T> IntoIterator for Stack<T> {
    type Item = T;
    type IntoIter = std::vec::IntoIter<T>;

    fn into_iter(self) -> Self::IntoIter {
        self.items.into_iter()
    }
}

fn main() {
    let mut stack = Stack::new();
    stack.push(1);
    stack.push(2);
    stack.push(3);

    for item in stack { // works because of IntoIterator
        println!("{item}");
    }
}

29. Building a REST API with Axum

axum is the most popular async web framework in Rust, built on top of tokio and hyper. It uses Rust's type system to make routing and request extraction ergonomic and safe.

Setup

# Cargo.toml
[dependencies]
axum      = "0.7"
tokio     = { version = "1", features = ["full"] }
serde     = { version = "1", features = ["derive"] }
serde_json = "1"
uuid      = { version = "1", features = ["v4"] }

Full CRUD API — Todo List

use axum::{
    extract::{Path, State},
    http::StatusCode,
    response::Json,
    routing::{delete, get, post, put},
    Router,
};
use serde::{Deserialize, Serialize};
use std::sync::{Arc, Mutex};
use uuid::Uuid;

// --- Models ---

#[derive(Debug, Clone, Serialize, Deserialize)]
struct Todo {
    id: String,
    title: String,
    completed: bool,
}

#[derive(Deserialize)]
struct CreateTodo {
    title: String,
}

#[derive(Deserialize)]
struct UpdateTodo {
    title: Option<String>,
    completed: Option<bool>,
}

// --- Shared state ---

type Db = Arc<Mutex<Vec<Todo>>>;

// --- Handlers ---

async fn list_todos(State(db): State<Db>) -> Json<Vec<Todo>> {
    let todos = db.lock().unwrap();
    Json(todos.clone())
}

async fn create_todo(
    State(db): State<Db>,
    Json(payload): Json<CreateTodo>,
) -> (StatusCode, Json<Todo>) {
    let todo = Todo {
        id: Uuid::new_v4().to_string(),
        title: payload.title,
        completed: false,
    };
    db.lock().unwrap().push(todo.clone());
    (StatusCode::CREATED, Json(todo))
}

async fn get_todo(
    State(db): State<Db>,
    Path(id): Path<String>,
) -> Result<Json<Todo>, StatusCode> {
    let todos = db.lock().unwrap();
    todos
        .iter()
        .find(|t| t.id == id)
        .cloned()
        .map(Json)
        .ok_or(StatusCode::NOT_FOUND)
}

async fn update_todo(
    State(db): State<Db>,
    Path(id): Path<String>,
    Json(payload): Json<UpdateTodo>,
) -> Result<Json<Todo>, StatusCode> {
    let mut todos = db.lock().unwrap();
    let todo = todos.iter_mut().find(|t| t.id == id).ok_or(StatusCode::NOT_FOUND)?;

    if let Some(title) = payload.title { todo.title = title; }
    if let Some(completed) = payload.completed { todo.completed = completed; }

    Ok(Json(todo.clone()))
}

async fn delete_todo(
    State(db): State<Db>,
    Path(id): Path<String>,
) -> StatusCode {
    let mut todos = db.lock().unwrap();
    let before = todos.len();
    todos.retain(|t| t.id != id);

    if todos.len() < before { StatusCode::NO_CONTENT }
    else { StatusCode::NOT_FOUND }
}

// --- Router ---

fn app(db: Db) -> Router {
    Router::new()
        .route("/todos",      get(list_todos).post(create_todo))
        .route("/todos/:id",  get(get_todo).put(update_todo).delete(delete_todo))
        .with_state(db)
}

// --- Main ---

#[tokio::main]
async fn main() {
    let db: Db = Arc::new(Mutex::new(vec![]));

    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    println!("listening on http://localhost:3000");

    axum::serve(listener, app(db)).await.unwrap();
}

Test it with curl

# Create todos
curl -s -X POST http://localhost:3000/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Learn Rust"}' | jq

curl -s -X POST http://localhost:3000/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Build an API"}' | jq

# List all
curl -s http://localhost:3000/todos | jq

# Get one (replace ID)
curl -s http://localhost:3000/todos/<id> | jq

# Update
curl -s -X PUT http://localhost:3000/todos/<id> \
  -H "Content-Type: application/json" \
  -d '{"completed": true}' | jq

# Delete
curl -s -X DELETE http://localhost:3000/todos/<id>

Adding middleware — request logging

use axum::middleware::{self, Next};
use axum::extract::Request;
use axum::response::Response;

async fn log_request(req: Request, next: Next) -> Response {
    let method = req.method().clone();
    let uri    = req.uri().clone();
    let res    = next.run(req).await;
    println!("{} {} → {}", method, uri, res.status());
    res
}

fn app(db: Db) -> Router {
    Router::new()
        .route("/todos",     get(list_todos).post(create_todo))
        .route("/todos/:id", get(get_todo).put(update_todo).delete(delete_todo))
        .layer(middleware::from_fn(log_request)) // add logging to all routes
        .with_state(db)
}

Wrapping Up

Concept	What it gives you
dyn Trait	Runtime polymorphism, heterogeneous collections
Deref	Transparent smart pointer ergonomics, auto-coercions
Drop	RAII — deterministic cleanup, no GC needed
Custom iterators	Any type can plug into Rust's iterator ecosystem
Axum	Type-safe, async REST APIs on top of tokio

The full series

Part	Topics
Part 1	Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching
Part 2	Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await
Part 3	Macros, Modules, Cargo, Testing, Unsafe, FFI
Part 4	Threads, Channels, Send/Sync, Mutex, Atomics, clap
Part 5	dyn Trait, Deref, Drop, Custom Iterators, Axum REST API

What's in Part 6?

Workspaces and multi-crate projects
serde — serialization deep dive
Benchmarking with criterion
Error handling patterns with thiserror and anyhow
Writing a real-world CLI + library crate

Found this useful? Drop a ❤️ and follow for Part 6!

Rust Concurrency: Threads, Channels, Mutex & Sync (Part 4)

mihir mohapatra — Thu, 21 May 2026 08:12:01 +0000

This is Part 4 of the Core Rust Concepts series.

Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching

Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await

Part 3 — Macros, Modules, Testing, Unsafe Rust, FFI

Threads
Message Passing with Channels
Send and Sync Traits
Mutex and RwLock
Atomics
Building a CLI Tool with clap

19. Threads

Rust's standard library provides OS threads via std::thread. The ownership and type system prevents data races at compile time — if your code compiles, it's free of data races. That's a guarantee no other systems language makes.

Spawning a thread

use std::thread;
use std::time::Duration;

fn main() {
    let handle = thread::spawn(|| {
        for i in 1..=5 {
            println!("thread: {i}");
            thread::sleep(Duration::from_millis(50));
        }
    });

    for i in 1..=3 {
        println!("main:   {i}");
        thread::sleep(Duration::from_millis(80));
    }

    handle.join().unwrap(); // wait for the thread to finish
}

Moving data into a thread

Use move to transfer ownership of data into the thread closure:

use std::thread;

fn main() {
    let data = vec![1, 2, 3, 4, 5];

    let handle = thread::spawn(move || {
        // data is moved into this thread
        let sum: i32 = data.iter().sum();
        println!("sum: {sum}");
    });

    // println!("{:?}", data); ← compile error: data was moved

    handle.join().unwrap();
}

Spawning many threads

use std::thread;

fn main() {
    let handles: Vec<_> = (0..8)
        .map(|i| {
            thread::spawn(move || {
                println!("worker {i} done");
                i * i
            })
        })
        .collect();

    let results: Vec<_> = handles
        .into_iter()
        .map(|h| h.join().unwrap())
        .collect();

    println!("squares: {:?}", results);
}

💡 thread::spawn returns a JoinHandle<T> where T is the return type of the closure. Always .join() your handles — a panicking thread silently fails otherwise.

20. Message Passing with Channels

Rust's standard library includes multiple-producer, single-consumer (mpsc) channels. The philosophy: "do not communicate by sharing memory; share memory by communicating."

Basic channel

use std::sync::mpsc;
use std::thread;

fn main() {
    let (tx, rx) = mpsc::channel();

    thread::spawn(move || {
        let msgs = vec!["hello", "from", "the", "thread"];
        for msg in msgs {
            tx.send(msg).unwrap();
        }
    });

    for received in rx {
        println!("got: {received}");
    }
}

Multiple producers

use std::sync::mpsc;
use std::thread;

fn main() {
    let (tx, rx) = mpsc::channel::<String>();

    for id in 0..4 {
        let tx_clone = tx.clone(); // each thread gets its own sender
        thread::spawn(move || {
            tx_clone.send(format!("msg from worker {id}")).unwrap();
        });
    }

    drop(tx); // drop the original so rx knows when all senders are gone

    for msg in rx {
        println!("{msg}");
    }
}

Synchronous channel (bounded)

use std::sync::mpsc;
use std::thread;

fn main() {
    // Buffer of 2 — sender blocks when full
    let (tx, rx) = mpsc::sync_channel::<i32>(2);

    thread::spawn(move || {
        for i in 0..5 {
            println!("sending {i}");
            tx.send(i).unwrap(); // blocks at i=2 until receiver reads
        }
    });

    thread::sleep(std::time::Duration::from_millis(200));

    for val in rx {
        println!("received {val}");
    }
}

💡 For more advanced channel patterns (broadcast, watch, oneshot), use the tokio::sync or crossbeam-channel crates.

21. Send and Sync Traits

These two marker traits are the foundation of Rust's fearless concurrency. You rarely implement them manually — the compiler derives them automatically.

Trait	Meaning
`Send`	Safe to transfer ownership to another thread
`Sync`	Safe to share a reference across threads (`&T` is `Send`)

use std::thread;
use std::rc::Rc;
use std::sync::Arc;

fn main() {
    // Rc<T> is NOT Send — can't move across threads
    // let rc = Rc::new(42);
    // thread::spawn(move || println!("{}", rc)); ← compile error!

    // Arc<T> IS Send — atomic reference counting
    let arc = Arc::new(42);
    let arc_clone = Arc::clone(&arc);

    thread::spawn(move || {
        println!("thread sees: {}", arc_clone);
    }).join().unwrap();

    println!("main sees: {}", arc);
}

Types and their Send/Sync status:

Type	Send	Sync
`i32`, `f64`, `bool`	✅	✅
`String`, `Vec<T>`	✅	✅
`Rc<T>`	❌	❌
`Arc<T>`	✅	✅
`RefCell<T>`	✅	❌
`Mutex<T>`	✅	✅
`*mut T` (raw pointer)	❌	❌

🦀 If you try to share a non-Sync type across threads, the compiler refuses to compile. No runtime surprises.

22. Mutex and RwLock

When multiple threads need to mutate shared data, use a Mutex (mutual exclusion lock). Wrap it in Arc to share ownership across threads.

Mutex

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap(); // blocks until lock acquired
            *num += 1;
        }); // lock is released here when `num` drops
        handles.push(handle);
    }

    for h in handles { h.join().unwrap(); }

    println!("result: {}", *counter.lock().unwrap()); // 10
}

RwLock — many readers, one writer

use std::sync::{Arc, RwLock};
use std::thread;

fn main() {
    let data = Arc::new(RwLock::new(vec![1, 2, 3]));

    // Spawn 4 reader threads
    let readers: Vec<_> = (0..4).map(|i| {
        let data = Arc::clone(&data);
        thread::spawn(move || {
            let r = data.read().unwrap(); // multiple readers allowed
            println!("reader {i}: {:?}", *r);
        })
    }).collect();

    // One writer thread
    let data_w = Arc::clone(&data);
    let writer = thread::spawn(move || {
        let mut w = data_w.write().unwrap(); // exclusive access
        w.push(4);
        println!("writer pushed 4");
    });

    for r in readers { r.join().unwrap(); }
    writer.join().unwrap();
}

Mutex vs RwLock:

	`Mutex<T>`	`RwLock<T>`
Readers	One at a time	Many simultaneously
Writers	One at a time	One at a time (exclusive)
Best for	Write-heavy workloads	Read-heavy workloads
Overhead	Lower	Higher

Avoiding deadlocks

use std::sync::{Arc, Mutex};

fn main() {
    let a = Arc::new(Mutex::new(1));
    let b = Arc::new(Mutex::new(2));

    // ✅ Always acquire locks in the same order
    {
        let _lock_a = a.lock().unwrap();
        let _lock_b = b.lock().unwrap();
        println!("safe");
    }

    // ❌ Acquiring in different orders across threads = deadlock risk
    // thread 1: lock a → lock b
    // thread 2: lock b → lock a  ← deadlock!
}

23. Atomics

For simple counters and flags shared between threads, std::sync::atomic types are faster than a Mutex — they use hardware atomic instructions with no locking.

use std::sync::Arc;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::thread;

fn main() {
    let counter = Arc::new(AtomicUsize::new(0));
    let mut handles = vec![];

    for _ in 0..8 {
        let counter = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            for _ in 0..1000 {
                counter.fetch_add(1, Ordering::Relaxed);
            }
        }));
    }

    for h in handles { h.join().unwrap(); }
    println!("total: {}", counter.load(Ordering::SeqCst)); // 8000
}

Memory ordering cheat sheet

Ordering	Use case
`Relaxed`	Counters — no ordering guarantees needed
`Acquire`	Load that synchronizes with a `Release` store
`Release`	Store that publishes data to other threads
`AcqRel`	Read-modify-write (e.g. `fetch_add` with sync)
`SeqCst`	Strongest — total order across all threads

use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::Arc;
use std::thread;

fn main() {
    let ready = Arc::new(AtomicBool::new(false));
    let ready_clone = Arc::clone(&ready);

    let worker = thread::spawn(move || {
        thread::sleep(std::time::Duration::from_millis(100));
        ready_clone.store(true, Ordering::Release);
        println!("worker: done");
    });

    // Spin-wait (not ideal in prod — use a Condvar or channel instead)
    while !ready.load(Ordering::Acquire) {
        thread::yield_now();
    }
    println!("main: worker finished");
    worker.join().unwrap();
}

💡 Available atomic types: AtomicBool, AtomicI8/16/32/64, AtomicU8/16/32/64, AtomicUsize, AtomicIsize, AtomicPtr<T>.

24. Building a CLI Tool with clap

clap is the standard Rust library for building command-line interfaces. It gives you argument parsing, help text, and subcommands with minimal boilerplate.

# Cargo.toml
[dependencies]
clap = { version = "4", features = ["derive"] }

Basic CLI

use clap::Parser;

/// A simple file word counter
#[derive(Parser, Debug)]
#[command(name = "wordcount")]
#[command(about = "Count words in a string or file", long_about = None)]
struct Cli {
    /// The text to count words in
    #[arg(short, long)]
    text: Option<String>,

    /// Show character count too
    #[arg(short, long, default_value_t = false)]
    chars: bool,

    /// Verbosity level
    #[arg(short, long, action = clap::ArgAction::Count)]
    verbose: u8,
}

fn main() {
    let cli = Cli::parse();

    let input = cli.text.unwrap_or_else(|| String::from("hello world"));
    let words = input.split_whitespace().count();

    if cli.verbose > 0 {
        println!("Input: {:?}", input);
    }

    println!("Words: {words}");

    if cli.chars {
        println!("Chars: {}", input.chars().count());
    }
}

Running it:

$ cargo run -- --text "the quick brown fox" --chars -v
Input: "the quick brown fox"
Words: 4
Chars: 19

$ cargo run -- --help
Count words in a string or file

Usage: wordcount [OPTIONS]

Options:
  -t, --text <TEXT>   The text to count words in
  -c, --chars         Show character count too
  -v, --verbose...    Verbosity level
  -h, --help          Print help

Subcommands

use clap::{Parser, Subcommand};

#[derive(Parser)]
#[command(name = "mytool", about = "A multi-command CLI")]
struct Cli {
    #[command(subcommand)]
    command: Commands,
}

#[derive(Subcommand)]
enum Commands {
    /// Add two numbers
    Add { a: f64, b: f64 },
    /// Multiply two numbers
    Mul { a: f64, b: f64 },
    /// Greet someone
    Greet {
        name: String,
        #[arg(short, long, default_value = "Hello")]
        greeting: String,
    },
}

fn main() {
    let cli = Cli::parse();

    match cli.command {
        Commands::Add { a, b } => println!("{} + {} = {}", a, b, a + b),
        Commands::Mul { a, b } => println!("{} × {} = {}", a, b, a * b),
        Commands::Greet { name, greeting } => println!("{greeting}, {name}!"),
    }
}

Running subcommands:

$ cargo run -- add 3.5 2.5
3.5 + 2.5 = 6

$ cargo run -- greet Alice --greeting "Hey"
Hey, Alice!

$ cargo run -- mul 6 7
6 × 7 = 42

💡 For a full production CLI, combine clap with anyhow for error handling, indicatif for progress bars, and colored or owo-colors for terminal color output.

Wrapping Up

Concept	What it gives you
Threads	OS-level parallelism, compile-time data race prevention
Channels	Safe message passing between threads (mpsc)
Send & Sync	Compiler-enforced thread-safety contracts
Mutex & RwLock	Shared mutable state without data races
Atomics	Lock-free counters and flags
clap	Production-grade CLI argument parsing

The full series so far

Part	Topics
Part 1	Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching
Part 2	Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await
Part 3	Macros, Modules, Cargo, Testing, Unsafe, FFI
Part 4	Threads, Channels, Send/Sync, Mutex, Atomics, clap

What's in Part 5?

Trait objects and dynamic dispatch (dyn Trait)
The Deref and Drop traits
Custom iterators
Building a real REST API with axum

Found this helpful? Drop a ❤️ and follow for Part 5!

Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part 3)

mihir mohapatra — Wed, 20 May 2026 06:59:05 +0000

This is Part 3 of the Core Rust Concepts series.

Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching

Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await

Macros
Modules & the Cargo Ecosystem
Testing in Rust
Closures as Return Types & Higher-Order Functions
Unsafe Rust
FFI — Calling C from Rust

13. Macros

Rust has two kinds of macros: declarative (macro_rules!) and procedural (proc macros). Both generate code at compile time — not at runtime.

Declarative Macros (`macro_rules!`)

These work by pattern matching on the syntax you pass in and expanding to new code.

// Define a macro
macro_rules! say_hello {
    () => {
        println!("Hello!");
    };
    ($name:expr) => {
        println!("Hello, {}!", $name);
    };
}

fn main() {
    say_hello!();            // Hello!
    say_hello!("Rustacean"); // Hello, Rustacean!
}

A more practical example — a map! macro that builds a HashMap:

macro_rules! map {
    ($($key:expr => $val:expr),*) => {{
        let mut m = std::collections::HashMap::new();
        $(m.insert($key, $val);)*
        m
    }};
}

fn main() {
    let scores = map!("Alice" => 95, "Bob" => 87, "Carol" => 92);
    println!("{:?}", scores);
}

Procedural Macros (Derive)

Proc macros operate on the token stream — used for #[derive(...)], custom attributes, and function-like macros.

// The most common proc macro you'll use — derive
#[derive(Debug, Clone, PartialEq)]
struct User {
    name: String,
    age: u32,
}

fn main() {
    let u1 = User { name: String::from("Alice"), age: 30 };
    let u2 = u1.clone();
    println!("{:?}", u1);       // Debug print
    println!("{}", u1 == u2);   // PartialEq: true
}

💡 Popular crates like serde use proc macros to generate serialization/deserialization code automatically with just #[derive(Serialize, Deserialize)].

14. Modules & the Cargo Ecosystem

Modules

Rust organizes code into a module tree. You define modules with mod, control visibility with pub, and bring items into scope with use.

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

    pub mod advanced {
        pub fn power(base: i32, exp: u32) -> i32 {
            base.pow(exp)
        }
    }
}

use math::advanced::power;

fn main() {
    println!("{}", math::add(3, 4));      // 7
    println!("{}", math::subtract(10, 4)); // 6
    println!("{}", power(2, 8));           // 256
}

Splitting across files

src/
├── main.rs
├── math.rs          ← mod math; in main.rs
└── math/
    └── advanced.rs  ← pub mod advanced; in math.rs

// main.rs
mod math;
use math::add;

fn main() {
    println!("{}", add(2, 3));
}

// math.rs
pub mod advanced;

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

Cargo — The Build System & Package Manager

# Cargo.toml
[package]
name    = "my_app"
version = "0.1.0"
edition = "2021"

[dependencies]
serde       = { version = "1", features = ["derive"] }
tokio       = { version = "1", features = ["full"] }
reqwest     = { version = "0.11", features = ["json"] }
anyhow      = "1"

[dev-dependencies]
pretty_assertions = "1"

Essential Cargo commands:

cargo new my_app        # create a new project
cargo build             # compile (debug)
cargo build --release   # compile (optimized)
cargo run               # build + run
cargo test              # run all tests
cargo doc --open        # generate and open docs
cargo add serde         # add a dependency
cargo update            # update dependencies
cargo clippy            # lint your code
cargo fmt               # auto-format

15. Testing in Rust

Testing is built into the language — no extra framework needed. Tests live right next to your code.

Unit Tests

pub fn divide(a: f64, b: f64) -> Option<f64> {
    if b == 0.0 { None } else { Some(a / b) }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_divide_normal() {
        assert_eq!(divide(10.0, 2.0), Some(5.0));
    }

    #[test]
    fn test_divide_by_zero() {
        assert_eq!(divide(5.0, 0.0), None);
    }

    #[test]
    #[should_panic(expected = "index out of bounds")]
    fn test_panic() {
        let v = vec![1, 2, 3];
        let _ = v[10]; // should panic
    }

    #[test]
    fn test_with_message() {
        let result = divide(9.0, 3.0);
        assert!(result.is_some(), "expected Some, got None");
        assert!((result.unwrap() - 3.0).abs() < f64::EPSILON);
    }
}

Run with:

cargo test                        # run all tests
cargo test test_divide            # run tests matching the name
cargo test -- --nocapture         # show println! output

Integration Tests

Integration tests live in a top-level tests/ folder and test your public API.

src/
└── lib.rs
tests/
└── integration_test.rs

// tests/integration_test.rs
use my_app::divide;

#[test]
fn test_public_api() {
    assert_eq!(divide(20.0, 4.0), Some(5.0));
}

Test with Result

#[test]
fn test_returns_result() -> Result<(), String> {
    let val = divide(10.0, 2.0).ok_or("division failed")?;
    assert_eq!(val, 5.0);
    Ok(())
}

💡 Use cargo test -- --test-threads=1 if tests share state and need to run sequentially.

16. Closures as Return Types & Higher-Order Functions

Rust can return closures from functions, enabling functional patterns like currying and function factories.

// Return a closure using impl Fn
fn make_adder(x: i32) -> impl Fn(i32) -> i32 {
    move |y| x + y
}

// Return a closure on the heap using Box<dyn Fn>
fn make_multiplier(x: i32) -> Box<dyn Fn(i32) -> i32> {
    Box::new(move |y| x * y)
}

fn apply_twice<F: Fn(i32) -> i32>(f: F, val: i32) -> i32 {
    f(f(val))
}

fn main() {
    let add5  = make_adder(5);
    let triple = make_multiplier(3);

    println!("{}", add5(10));            // 15
    println!("{}", triple(7));           // 21
    println!("{}", apply_twice(add5, 0)); // 10
    println!("{}", apply_twice(|x| x * 2, 3)); // 12
}

When to use impl Fn vs Box<dyn Fn>:

	`impl Fn`	`Box<dyn Fn>`
Storage in struct	❌	✅
Return from function	✅	✅
Runtime cost	Zero	Small heap alloc
Works in collections	❌	✅

17. Unsafe Rust

Rust's safety guarantees are enforced at compile time — but sometimes you need to step outside them. unsafe blocks let you do four things the borrow checker won't normally allow.

What unsafe unlocks:

Dereference raw pointers
Call unsafe functions or C functions
Access or mutate static mutable variables
Implement unsafe traits

fn main() {
    // Raw pointers
    let x = 42;
    let r: *const i32 = &x;           // create raw pointer (safe)

    unsafe {
        println!("{}", *r);            // dereference (unsafe)
    }

    // Mutable raw pointer
    let mut y = 10;
    let rw: *mut i32 = &mut y;
    unsafe {
        *rw += 1;
    }
    println!("{}", y); // 11
}

Unsafe functions:

unsafe fn dangerous_operation(ptr: *mut i32, len: usize) {
    for i in 0..len {
        *ptr.add(i) *= 2;
    }
}

fn main() {
    let mut data = vec![1, 2, 3, 4, 5];
    let ptr = data.as_mut_ptr();
    let len = data.len();

    unsafe {
        dangerous_operation(ptr, len);
    }

    println!("{:?}", data); // [2, 4, 6, 8, 10]
}

Static mutable variables:

static mut COUNTER: u32 = 0;

fn increment() {
    unsafe { COUNTER += 1; }
}

fn main() {
    increment();
    increment();
    unsafe { println!("Counter: {}", COUNTER); } // 2
}

⚠️ unsafe doesn't turn off the borrow checker entirely — it only unlocks those four specific superpowers. You're taking responsibility for ensuring correctness in those blocks. Keep unsafe blocks as small as possible and document why they're safe.

18. FFI — Calling C from Rust

Rust can interoperate with C libraries using its Foreign Function Interface. This is how Rust wraps system APIs, game engines, and existing C codebases.

Calling a C standard library function

use std::ffi::CString;
use std::os::raw::c_char;

extern "C" {
    fn strlen(s: *const c_char) -> usize;
    fn abs(x: i32) -> i32;
}

fn main() {
    // Calling C's abs()
    let result = unsafe { abs(-42) };
    println!("{}", result); // 42

    // Calling C's strlen()
    let s = CString::new("hello").unwrap();
    let len = unsafe { strlen(s.as_ptr()) };
    println!("{}", len); // 5
}

Exposing Rust to C

// lib.rs — compile with: rustc --crate-type=cdylib

#[no_mangle]
pub extern "C" fn add(a: i32, b: i32) -> i32 {
    a + b
}

// main.c — link against the compiled Rust library
extern int add(int a, int b);

int main() {
    printf("%d\n", add(3, 4)); // 7
}

Using `bindgen` for real C libraries

For larger C libraries, use bindgen to auto-generate Rust bindings:

cargo add bindgen --build

// build.rs
fn main() {
    bindgen::Builder::default()
        .header("wrapper.h")
        .generate()
        .unwrap()
        .write_to_file("src/bindings.rs")
        .unwrap();
}

💡 Most real-world FFI is wrapped in a safe Rust API. The unsafe extern calls live in a *-sys crate (e.g. openssl-sys), and a higher-level crate wraps them in a safe interface (e.g. openssl).

Wrapping Up

Here's what Part 3 covered:

Concept	What it gives you
Macros	Compile-time code generation, reduce boilerplate
Modules & Cargo	Code organization, dependency management
Testing	Built-in unit, integration, and doc tests
Higher-order functions	Functional patterns, closures as values
Unsafe Rust	Raw pointers and low-level control when needed
FFI	Interop with C libraries and system APIs

What's in Part 4?

Concurrency with threads and channels
The Send and Sync traits
Mutex, RwLock, and atomics
Building a real CLI tool with clap

If this helped, drop a ❤️ and follow for Part 4!

Advanced Rust Concepts: Iterators, Closures, Generics & More (Part 2)

mihir mohapatra — Tue, 19 May 2026 10:30:04 +0000

This is Part 2 of the Core Rust Concepts series. If you haven't read Part 1, start there — it covers Ownership, Borrowing, Lifetimes, Traits, Result/Option, and Pattern Matching.

Closures
Iterators & Iterator Adaptors
Generics
Enums & the Type System
Smart Pointers
Async / Await

7. Closures

Closures are anonymous functions you can store in variables or pass as arguments. Unlike regular functions, they can capture variables from the surrounding scope.

Rust has three closure traits depending on how they use the environment:

Trait	Captures	Can call
`Fn`	Immutable borrow	Many times
`FnMut`	Mutable borrow	Many times
`FnOnce`	Takes ownership	Once only

fn apply<F: Fn(i32) -> i32>(f: F, val: i32) -> i32 {
    f(val)
}

fn main() {
    let factor = 3;
    let multiply = |x| x * factor; // captures `factor` from scope

    println!("{}", apply(multiply, 5)); // 15

    // FnOnce: consumes the captured value
    let s = String::from("hello");
    let consume = move || println!("{}", s); // takes ownership of s
    consume();
    // consume(); ← error: already moved
}

🦀 Use move before a closure to force it to take ownership of captured variables — common in threads and async code.

8. Iterators & Iterator Adaptors

Rust's iterator system is one of its best features. Iterators are lazy — nothing executes until you call a consumer. You chain adaptor methods and the compiler optimizes the whole pipeline as if you wrote a hand-rolled loop.

fn main() {
    let numbers = vec![1, 2, 3, 4, 5, 6];

    // chain: filter → map → collect
    let result: Vec<i32> = numbers
        .iter()
        .filter(|&&x| x % 2 == 0)  // keep even numbers
        .map(|x| x * 10)            // multiply by 10
        .collect();                 // [20, 40, 60]

    let sum: i32 = (1..=100).sum(); // 5050 — no loop needed!

    // enumerate + take
    for (i, val) in numbers.iter().enumerate().take(3) {
        println!("[{i}] = {val}");
    }
}

Adaptors (lazy — don't run yet):

map, filter, flat_map
take, skip, enumerate
zip, chain, peekable

Consumers (trigger evaluation):

collect, sum, product
count, max, min
find, any, all, fold

💡 Prefer iterator chains over manual for loops — they're often faster, always more expressive, and the compiler can auto-vectorize them.

9. Generics

Generics let you write code that works for any type, with zero runtime overhead. Rust uses monomorphization — at compile time it generates a concrete version for each type you actually use. No boxing, no vtable lookup.

// Generic struct with trait bounds
struct Pair<T> {
    first: T,
    second: T,
}

impl<T: std::fmt::Display + PartialOrd> Pair<T> {
    fn larger(&self) -> &T {
        if self.first > self.second { &self.first }
        else { &self.second }
    }
}

fn main() {
    let nums = Pair { first: 5, second: 10 };
    let strs = Pair { first: "apple", second: "banana" };

    println!("{}", nums.larger());  // 10
    println!("{}", strs.larger()); // "banana"
}

Trait bounds (the T: Display + PartialOrd part) let you constrain what types are allowed. You can also use the where clause for readability:

fn print_larger<T>(a: T, b: T)
where
    T: std::fmt::Display + PartialOrd,
{
    if a > b { println!("{a}") } else { println!("{b}") }
}

10. Enums & the Type System

Rust's enum is far more powerful than in most languages — each variant can hold different data. This makes them algebraic data types, great for modelling state machines, ASTs, or any "one of these shapes" scenario.

enum Shape {
    Circle(f64),                          // radius
    Rectangle(f64, f64),                  // width, height
    Triangle { base: f64, height: f64 },  // named fields
}

impl Shape {
    fn area(&self) -> f64 {
        match self {
            Shape::Circle(r)               => 3.14159 * r * r,
            Shape::Rectangle(w, h)         => w * h,
            Shape::Triangle { base, height } => 0.5 * base * height,
        }
    }
}

fn main() {
    let shapes = vec![
        Shape::Circle(5.0),
        Shape::Rectangle(3.0, 4.0),
        Shape::Triangle { base: 6.0, height: 8.0 },
    ];

    for s in &shapes {
        println!("area: {:.2}", s.area());
    }
}

Output:

area: 78.54
area: 12.00
area: 24.00

Enums + match is how Rust replaces inheritance. No subclassing needed — just model your variants explicitly and let the compiler verify you handle all of them.

11. Smart Pointers

When the ownership rules feel too strict, smart pointers offer controlled escape hatches — each with clearly defined trade-offs.

Type	Purpose	Thread-safe?
`Box<T>`	Heap allocation, single owner	Yes
`Rc<T>`	Shared ownership, ref-counted	No
`Arc<T>`	Shared ownership, atomic ref-count	Yes
`RefCell<T>`	Interior mutability, runtime borrow check	No

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    // Box: heap-allocate a value
    let boxed = Box::new(42);
    println!("{}", *boxed); // 42

    // Rc: multiple owners (single-threaded)
    let shared = Rc::new(String::from("shared"));
    let clone1 = Rc::clone(&shared);
    println!("ref count: {}", Rc::strong_count(&shared)); // 2
    drop(clone1);
    println!("ref count: {}", Rc::strong_count(&shared)); // 1

    // RefCell: mutate through a shared reference
    let data = RefCell::new(vec![1, 2, 3]);
    data.borrow_mut().push(4);
    println!("{:?}", data.borrow()); // [1, 2, 3, 4]
}

Common pattern — Rc<RefCell<T>> gives you multiple owners that can all mutate the data:

use std::rc::Rc;
use std::cell::RefCell;

let shared_vec = Rc::new(RefCell::new(vec![1, 2]));
let a = Rc::clone(&shared_vec);
let b = Rc::clone(&shared_vec);

a.borrow_mut().push(3);
b.borrow_mut().push(4);

println!("{:?}", shared_vec.borrow()); // [1, 2, 3, 4]

For multi-threaded code, swap Rc → Arc and RefCell → Mutex.

12. Async / Await

Rust's async model is built on futures — values that represent work not yet completed. Marking a function async makes it return a Future. You use .await to yield control until it resolves. A runtime like tokio drives the futures.

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }

use tokio::time::{sleep, Duration};

async fn fetch_data(id: u32) -> String {
    sleep(Duration::from_millis(100)).await;
    format!("data for id={id}")
}

#[tokio::main]
async fn main() {
    // Sequential — takes ~200ms
    // let a = fetch_data(1).await;
    // let b = fetch_data(2).await;

    // Concurrent — takes ~100ms
    let (a, b) = tokio::join!(
        fetch_data(1),
        fetch_data(2),
    );

    println!("{}", a);
    println!("{}", b);
}

Key async concepts:

// Spawn a task (like a lightweight thread)
tokio::spawn(async {
    println!("running concurrently");
});

// Select: race multiple futures, use whichever finishes first
tokio::select! {
    result = fetch_data(1) => println!("got: {result}"),
    _ = sleep(Duration::from_secs(1)) => println!("timed out"),
}

💡 Unlike Go or Erlang, Rust async has zero runtime overhead — futures compile down to state machines with no hidden heap allocations per task.

Wrapping Up

Here's a quick summary of what Part 2 covered:

Concept	What it gives you
Closures	Capture-by-reference or by-value anonymous functions
Iterators	Lazy, composable, zero-cost data pipelines
Generics	Monomorphized, compile-time polymorphism
Enums (ADTs)	Model complex state without inheritance
Smart Pointers	Heap, shared ownership, and interior mutability
Async/Await	Non-blocking concurrency with tokio

What's next?

Part 3 will cover:

Macros (macro_rules! and proc macros)
Modules and the Cargo ecosystem
Testing in Rust
Unsafe Rust and FFI

Found this useful? Drop a ❤️ and follow for Part 3!

Core Rust Concepts Every Developer Should Know

mihir mohapatra — Mon, 18 May 2026 09:33:32 +0000

Rust is one of the most loved programming languages — and for good reason. It gives you systems-level control with memory safety guarantees, all enforced at compile time. No garbage collector, no runtime overhead, no segfaults.

This post walks through 6 core concepts you need to understand Rust properly.

Ownership & Move Semantics
Borrowing & References
Lifetimes
Structs & Traits
Error Handling with Result & Option
Pattern Matching

1. Ownership & Move Semantics

Every value in Rust has a single owner. When the owner goes out of scope, the value is automatically dropped — no garbage collector needed. When you assign a value to another variable, ownership moves.

🦀 Rule: Each value has exactly one owner. When the owner is gone, the memory is freed. No dangling pointers, no double-frees.

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;  // s1 is MOVED into s2

    // println!("{}", s1); ← compile error: value moved!
    println!("{}", s2);  // ✓ s2 is the owner now
}

// To copy instead of move, use .clone():
let s3 = s2.clone();
println!("{} {}", s2, s3);  // both are valid

Ownership flow:

s1 owns "hello"  →  move  →  s2 owns "hello"  →  drop  →  s1 is invalid

2. Borrowing & References

Instead of moving, you can borrow a value using a reference (&). Immutable borrows allow many readers simultaneously. Mutable borrows (&mut) are exclusive — you can't have other borrows active at the same time.

The rules:

You can have many immutable references (&T) at once
OR you can have one mutable reference (&mut T) — but not both

fn print_len(s: &String) {        // borrows, does not own
    println!("length: {}", s.len());
}

fn append(s: &mut String) {       // mutable borrow
    s.push_str(" world");
}

fn main() {
    let mut s = String::from("hello");
    print_len(&s);       // s is still valid after this
    append(&mut s);
    println!("{}", s);   // "hello world"
}

3. Lifetimes

Lifetimes are Rust's way of ensuring references never outlive the data they point to. In most cases the compiler infers them, but sometimes you need to annotate explicitly with 'a syntax.

💡 Lifetimes don't change how long data lives — they describe relationships between references so the compiler can verify safety at compile time.

// 'a means: output lives at least as long as both inputs
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

fn main() {
    let s1 = String::from("long string");
    let result;
    {
        let s2 = String::from("xyz");
        result = longest(s1.as_str(), s2.as_str());
        println!("{}", result);  // ✓ both alive here
    }
    // println!("{}", result); ← error: s2 dropped!
}

4. Structs & Traits

Rust uses struct to define custom data types and trait to define shared behavior — similar to interfaces in other languages. A type can implement many traits. The compiler enforces trait contracts statically, with zero runtime overhead.

trait Describe {
    fn describe(&self) -> String;
}

struct Circle { radius: f64 }
struct Rectangle { width: f64, height: f64 }

impl Describe for Circle {
    fn describe(&self) -> String {
        format!("Circle with radius {}", self.radius)
    }
}

impl Describe for Rectangle {
    fn describe(&self) -> String {
        format!("{}×{} rectangle", self.width, self.height)
    }
}

fn print_shape(shape: &impl Describe) {
    println!("{}", shape.describe());
}

fn main() {
    print_shape(&Circle { radius: 3.0 });
    print_shape(&Rectangle { width: 4.0, height: 5.0 });
}

Output:

Circle with radius 3
4×5 rectangle

5. Error Handling with Result & Option

Rust has no exceptions. Instead, functions that can fail return Result<T, E> and functions that may return nothing return Option<T>. The ? operator makes propagating errors ergonomic.

use std::num::ParseIntError;

fn double_parse(s: &str) -> Result<i32, ParseIntError> {
    let n = s.parse::<i32>()?;  // ? returns early on error
    Ok(n * 2)
}

fn main() {
    match double_parse("21") {
        Ok(val)  => println!("Result: {}", val),  // 42
        Err(e)   => println!("Error: {}", e),
    }

    // Option: Some or None
    let items = vec![1, 2, 3];
    if let Some(first) = items.first() {
        println!("first: {}", first);
    }
}

Comparison with other languages:

Language	Error model
Rust	`Result<T, E>` — explicit, compiler-enforced
Go	`(value, error)` — explicit but not enforced
Java/Python	Exceptions — implicit, can be ignored
C	Return codes — easy to ignore

6. Pattern Matching

The match expression is Rust's powerhouse. It's exhaustive — the compiler forces you to handle every case. You can match on values, types, struct fields, ranges, and more, all with destructuring.

enum Command {
    Quit,
    Move { x: i32, y: i32 },
    Print(String),
}

fn handle(cmd: Command) {
    match cmd {
        Command::Quit               => println!("Quit!"),
        Command::Move { x, y }    => println!("Move to ({x},{y})"),
        Command::Print(msg)        => println!("Msg: {msg}"),
    }
}

// Guards and ranges
let score = 85;
let grade = match score {
    90..=100 => "A",
    80..=89  => "B",
    70..=79  => "C",
    _        => "F",
};
println!("Grade: {grade}");

Wrapping Up

These six concepts form the backbone of Rust's unique approach to safe, fast systems programming:

Concept	What it gives you
Ownership	Memory safety without a GC
Borrowing	Share data safely, concurrently
Lifetimes	Compile-time dangling pointer prevention
Traits	Zero-cost polymorphism
Result/Option	Explicit, unignorable error handling
Pattern matching	Exhaustive, expressive control flow

The best way to learn Rust is to fight the borrow checker — every error it throws is teaching you something real about memory. Start with The Rust Book (it's free!) and Rustlings for hands-on exercises.

If this helped you, drop a ❤️ and share with someone learning Rust!

DEV Community: mihir mohapatra

I Built a Production-Oriented Multi-Provider AI Chatbot in Rust — Here's How

Why Rust for an AI Backend?

What It Does

Architecture Overview

The Provider Abstraction

Shared Conversation State

Dual-Mode: Web UI + CLI

Quick Start

Option A: No Rust Required

Option B: From Source

Provider Configuration

Claude (Anthropic)

OpenAI

Ollama (Local — no API key needed)

OpenRouter (access any model via OpenAI-compatible API)

Docker

Rust vs Python: Backend Performance Perspective

What's Next (Roadmap)

Try It / Contribute

Rust Concepts: Serde, Error Handling, Benchmarking & Workspaces (Part 6)

Table of Contents

30. Serde — Serialization Deep Dive

Setup

Basic serialize / deserialize

Field attributes

Enums with serde

Custom serialize / deserialize

Working with dynamic JSON (serde_json::Value)

31. Error Handling with thiserror and anyhow

thiserror — define your own error types

anyhow — ergonomic error handling in applications

thiserror vs anyhow — when to use which

Combining both

32. Benchmarking with Criterion

Basic benchmark

Benchmarking with input sizes

What black_box does

33. Workspaces & Multi-Crate Projects

Workspace layout

Root Cargo.toml

core/Cargo.toml

cli/Cargo.toml

Sharing types across crates

Useful workspace commands

34. Writing a Real-World CLI + Library Crate

Library: crates/filestat-core/src/lib.rs

CLI: crates/filestat-cli/src/main.rs

Wrapping Up Part 6

The Complete Series

Where to Go Next

Building a Real-Time Collaborative Task Board: How Gemini Helped Me Build for the Google I/O Challenge 2026 🚀

🚀 Google I/O Challenge 2026: Collaborative Task Board

🎨 Creative Vision & Application Features

Key Capabilities Included:

🤖 Co-Architecting with Gemini on AI Studio

🛠️ Tech Stack & Implementation Details

💭 Reflection & Google I/O Appreciation

First Look: Building the Agentic Future with Gemini 3.5 Flash and Antigravity 2.0

The Core Primitives

1. Zero-Friction Orchestration with Antigravity 2.0

2. Speed Run: From Prompt to Play Store

3. The New Protocol: Agent2Agent (A2A)

Verdict for Builders

References

Rust Concepts: dyn Trait, Custom Iterators, Deref/Drop & Axum REST API (Part 5)

Table of Contents

25. Trait Objects and Dynamic Dispatch

Static vs Dynamic dispatch

When to use dyn Trait vs impl Trait

Object-safe traits

Real-world pattern — plugin system

26. The Deref Trait

Deref coercion chain

DerefMut

27. The Drop Trait

Dropping early

Drop in practice — RAII pattern

28. Custom Iterators

A real-world custom iterator — paginated results

Working with dynamic JSON (`serde_json::Value`)

What `black_box` does

Library: `crates/filestat-core/src/lib.rs`

CLI: `crates/filestat-cli/src/main.rs`

When to use `dyn Trait` vs `impl Trait`

Declarative Macros (`macro_rules!`)

Using `bindgen` for real C libraries