Forem: mihir mohapatra

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!

Forem: mihir mohapatra

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

IntoIterator — making structs work in for loops

29. Building a REST API with Axum

Setup

Full CRUD API — Todo List

Test it with curl

Adding middleware — request logging

Wrapping Up

The full series

What's in Part 6?

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

Table of Contents

19. Threads

Spawning a thread

Moving data into a thread

Spawning many threads

20. Message Passing with Channels

Basic channel

Multiple producers

Synchronous channel (bounded)

21. Send and Sync Traits

22. Mutex and RwLock

Mutex

RwLock — many readers, one writer

Avoiding deadlocks

23. Atomics

Memory ordering cheat sheet

24. Building a CLI Tool with clap

Basic CLI

Subcommands

Wrapping Up

The full series so far

What's in Part 5?

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

Table of Contents

13. Macros

Declarative Macros (macro_rules!)

Procedural Macros (Derive)

14. Modules & the Cargo Ecosystem

Modules

Splitting across files

Cargo — The Build System & Package Manager

15. Testing in Rust

Unit Tests

Integration Tests

Test with Result

16. Closures as Return Types & Higher-Order Functions

17. Unsafe Rust

18. FFI — Calling C from Rust

Calling a C standard library function

Exposing Rust to C

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

Declarative Macros (`macro_rules!`)

Using `bindgen` for real C libraries