Forem: Subesh Yadav

Day 30 of #100DaysOfRust: Reference Counting with Rc

Subesh Yadav — Wed, 17 Sep 2025 16:19:18 +0000

Today I explored Rc, the Reference Counted Smart Pointer in Rust. This is where ownership gets interesting—sometimes a value might need multiple owners, and Rc provides exactly that functionality.

🔄 Why Rc?

Normally, ownership in Rust is strict: only one owner exists for any given value. But in real-world cases, multiple parts of a program may need to share access. For example, in graph structures, multiple edges may point to the same node. That node shouldn’t be deallocated until all edges stop pointing to it.

Rc<T> keeps track of the number of references to a value. Once all references are gone, the value is safely cleaned up.

👉 Think of Rc like a TV in a family room: everyone can watch while they’re in the room, and only when the last person leaves is the TV turned off.

⚠️ Rc works only in single-threaded programs. For multithreading, Rust provides Arc<T> (Atomic Reference Counting).

📝 Example: Shared Ownership in Lists

Let’s revisit the cons list example. If we use Box<T> for ownership, we hit a problem:

enum List {
    Cons(i32, Box<List>),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let a = Cons(5, Box::new(Cons(10, Box::new(Nil))));
    let b = Cons(3, Box::new(a));
    let c = Cons(4, Box::new(a)); // ❌ Error: a was moved
}

This fails because a is moved into b, so it can’t also be used in c.

✅ Fixing with Rc

By using Rc, we enable multiple ownership:

use std::rc::Rc;

enum List {
    Cons(i32, Rc<List>),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
    let b = Cons(3, Rc::clone(&a));
    let c = Cons(4, Rc::clone(&a));
}

Here, Rc::clone(&a) increments the reference count instead of deeply copying the data. Now a, b, and c all share ownership.

📊 Tracking Reference Counts

We can observe how reference counts change with Rc::strong_count:

use std::rc::Rc;

enum List {
    Cons(i32, Rc<List>),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
    println!("count after creating a = {}", Rc::strong_count(&a));
    let b = Cons(3, Rc::clone(&a));
    println!("count after creating b = {}", Rc::strong_count(&a));
    {
        let c = Cons(4, Rc::clone(&a));
        println!("count after creating c = {}", Rc::strong_count(&a));
    }
    println!("count after c goes out of scope = {}", Rc::strong_count(&a));
}

Output:

count after creating a = 1
count after creating b = 2
count after creating c = 3
count after c goes out of scope = 2

The reference count goes up with every Rc::clone and down when a reference goes out of scope. When it finally reaches 0, the data is deallocated.

🚫 Why Rc Only Allows Immutable References

Rc<T> lets you share ownership via immutable references. If multiple owners could also mutate the data, Rust’s borrowing rules would be violated (e.g., multiple mutable borrows at once).

But sometimes, we do want shared mutable access. That’s where the interior mutability pattern comes in, using RefCell<T> alongside Rc<T>. I’ll explore this in the next session.

🧠 Summary

Rc<T> enables multiple ownership through reference counting.
Cloning with Rc::clone increments the count instead of deep-copying.
When the last reference is dropped, the data is freed.
Best for single-threaded scenarios where shared ownership is needed.
For mutation, combine with RefCell<T> (coming up next!).

🚀 That wraps up Day 30 of #100DaysOfRust! Today I learned how Rc<T> provides shared ownership and safe cleanup in Rust.

Tomorrow: Interior Mutability with RefCell.

Day 29 of #100DaysOfRust: The Drop Trait and Resource Cleanup

Subesh Yadav — Wed, 17 Sep 2025 15:56:56 +0000

Today’s focus was on the Drop trait, one of the most important traits in Rust’s memory and resource management story. After learning about smart pointers and deref coercion, we now dive into how Rust automatically cleans up values when they go out of scope, and how we can customize this behavior.

🧹 What is the Drop Trait?

The Drop trait allows you to specify what should happen when a value goes out of scope. It’s particularly useful for cleaning up resources like:

Memory allocations
File handles
Network connections
Locks

In other languages, forgetting to free these resources could cause crashes or memory leaks. Rust’s Drop trait ensures cleanup is handled automatically.

The trait requires implementing a single method:

impl Drop for MyType {
    fn drop(&mut self) {
        // cleanup code here
    }
}

Rust then inserts calls to this method automatically when the value goes out of scope.

🛠 Example: Custom Smart Pointer with Drop

Let’s implement a simple smart pointer to see how Drop works.

struct CustomSmartPointer {
    data: String,
}

impl Drop for CustomSmartPointer {
    fn drop(&mut self) {
        println!("Dropping CustomSmartPointer with data `{}`!", self.data);
    }
}

fn main() {
    let c = CustomSmartPointer {
        data: String::from("my stuff"),
    };
    let d = CustomSmartPointer {
        data: String::from("other stuff"),
    };
    println!("CustomSmartPointers created.");
}

Output:

CustomSmartPointers created.
Dropping CustomSmartPointer with data `other stuff`!
Dropping CustomSmartPointer with data `my stuff`!

Notice how values are dropped in the reverse order of their creation.

🚫 You Can’t Call Drop Directly

If you try to explicitly call c.drop(), Rust won’t allow it:

fn main() {
    let c = CustomSmartPointer {
        data: String::from("some data"),
    };
    c.drop(); // ❌ not allowed
}

You’ll get this compiler error:

error[E0040]: explicit use of destructor method
help: consider using `drop` function

This is to prevent double frees (Rust automatically calls drop at the end of the scope).

✅ Forcing Early Drop with `std::mem::drop`

If you do need to clean up a value before the end of its scope, you can use the drop function from Rust’s standard library:

fn main() {
    let c = CustomSmartPointer {
        data: String::from("some data"),
    };
    println!("CustomSmartPointer created.");
    drop(c);
    println!("CustomSmartPointer dropped before the end of main.");
}

Output:

CustomSmartPointer created.
Dropping CustomSmartPointer with data `some data`!
CustomSmartPointer dropped before the end of main.

This way, the cleanup code runs exactly when you want.

💡 Why Drop Matters

The Drop trait is everywhere in Rust’s standard library:

Box<T> deallocates heap memory when dropped.
Vec<T> and String clean up their buffers.
File and network types close their handles safely.
Mutexes release their locks.

It ensures Rust programs are safe, memory-efficient, and free from resource leaks.

🧠 Key Takeaways

The Drop trait runs cleanup code when values go out of scope.
Rust automatically calls drop; you don’t have to (and can’t) call it directly.
Use std::mem::drop to clean up resources before scope ends.
Variables are dropped in reverse order of creation.
Drop underpins Rust’s safe and predictable memory management.

That’s all for Day 29! 🚀 Tomorrow, I’ll continue exploring more smart pointers and their patterns.

👉 Follow me on my #100DaysOfRust journey!

Day 28 of #100DaysOfRust: Smart Pointers and Deref Coercion

Subesh Yadav — Wed, 17 Sep 2025 15:38:45 +0000

Today’s learning was all about treating smart pointers like regular references by implementing the Deref trait, exploring deref coercion, and understanding how it interacts with mutability.

📌 Following References to Values

A regular reference (&T) points to a value stored elsewhere. To access the value, we use the dereference operator *:

fn main() {
    let x = 5;
    let y = &x;

    assert_eq!(5, x);
    assert_eq!(5, *y);
}

Here *y follows the reference to get the value 5. Without *, the comparison won’t compile because {integer} and &{integer} are different types.

📦 Using Box Like a Reference

Smart pointers like Box<T> behave similarly to references when dereferenced:

fn main() {
    let x = 5;
    let y = Box::new(x);

    assert_eq!(5, x);
    assert_eq!(5, *y);
}

🛠 Defining Our Own Smart Pointer

We can define our own smart pointer MyBox<T>:

struct MyBox<T>(T);

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

But trying to dereference *y will fail until we implement the Deref trait.

🔗 Implementing the Deref Trait

To enable dereferencing:

use std::ops::Deref;

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

    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

Now *y works just like with Box<T>.

Behind the scenes:

*(y.deref())

This happens automatically whenever we use *.

🔄 Implicit Deref Coercions

Deref coercion allows automatic conversion between references:

From &T to &U when T: Deref<Target=U>
From &mut T to &mut U when T: DerefMut<Target=U>
From &mut T to &U when T: Deref<Target=U>

Example with MyBox<String>:

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

fn main() {
    let m = MyBox::new(String::from("Rust"));
    hello(&m); // Works because of deref coercion
}

Without coercion, we’d need:

hello(&(*m)[..]);

Much harder to read!

🔐 Deref and Mutability

&T → &U works with Deref.
&mut T → &mut U works with DerefMut.
&mut T → &U is also allowed.
❌ But &T → &mut U is not allowed, because it could break Rust’s borrowing rules.

This ensures safety and prevents undefined behavior.

🧠 Summary

Regular references require * to access the value.
Box<T> and custom smart pointers can implement Deref to behave like references.
Deref coercion simplifies function calls by automatically converting types.
Mutability rules ensure safety: mutable → immutable works, but immutable → mutable does not.

Rust’s deref system is a zero-cost abstraction: all conversions happen at compile time with no runtime cost.

🚀 That’s all for Day 28! Tomorrow, I’ll continue exploring more about **smart pointers and their advanced use

Day 27 of #100DaysOfRust: Introduction to Smart Pointers in Rust

Subesh Yadav — Wed, 17 Sep 2025 15:23:56 +0000

Today, I began exploring smart pointers, one of the more advanced but essential topics in Rust. While pointers are a common concept across languages, smart pointers in Rust combine ownership, borrowing, and memory safety into powerful tools.

🔹 What Are Smart Pointers?

A pointer is simply a variable that contains the memory address of some data. The most familiar pointer in Rust is a reference (&), which borrows data but doesn’t own it.

Smart pointers go beyond this. They are data structures that act like pointers but come with additional metadata and capabilities. Unlike references, smart pointers often own the data they point to.

Some examples of smart pointers in Rust:

String and Vec<T> (yes, you’ve already been using them!)
Box<T> – Heap allocation
Rc<T> – Reference counting (multiple owners)
RefCell<T> – Borrowing rules enforced at runtime

Most smart pointers are implemented using structs and rely on two critical traits:

Deref – Makes smart pointers behave like references.
Drop – Customizes behavior when the value goes out of scope.

In this post, I’ll focus on Box<T>, the simplest smart pointer.

📦 Using Box to Point to Data on the Heap

A box lets you store data on the heap instead of the stack. On the stack, only a small pointer to the heap data is stored.

When to Use Box:

When the size of a type is unknown at compile time.
When transferring ownership of large data without copying it.
When working with trait objects (polymorphism).

Example: Storing Data on the Heap

fn main() {
    let b = Box::new(5);
    println!("b = {b}");
}

➡️ This stores 5 on the heap, and the box itself is on the stack.

When the box goes out of scope, both the stack pointer and heap memory are cleaned up automatically.

🔁 Enabling Recursive Types with Boxes

One of the most common uses of Box<T> is to enable recursive types.

Let’s look at the classic cons list (a recursive data structure from Lisp).

First Attempt (Does Not Compile)

enum List {
    Cons(i32, List),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let list = Cons(1, Cons(2, Cons(3, Nil)));
}

➡️ This fails because Rust cannot determine how much memory the recursive type needs—it could be infinite!

Fixing with Box

enum List {
    Cons(i32, Box<List>),
    Nil,
}

use crate::List::{Cons, Nil};

fn main() {
    let list = Cons(1, Box::new(Cons(2, Box::new(Cons(3, Box::new(Nil))))));
}

➡️ By wrapping the recursive type in Box, Rust knows the size (a fixed pointer size) and can compile the program.

Why This Works

Each Cons contains an i32 and a pointer (Box) to the next element.
The recursion ends with Nil.
Memory usage is predictable because Rust only needs to store the pointer size for the box.

🧠 Key Takeaways

Smart pointers own the data they point to, unlike references.
Box<T> moves data to the heap but keeps pointer size fixed on the stack.
Recursive types like linked lists require Box<T> to work.
Boxes are lightweight: they provide indirection without extra overhead.
Traits Deref and Drop make smart pointers behave seamlessly.

This was my first step into smart pointers. Next, I’ll explore Deref, Drop, and other smart pointers like Rc<T> and RefCell<T>, along with advanced patterns like interior mutability and reference cycles.

🚀 Follow me for more updates on my #100DaysOfRust journey!

Day 26 of #100DaysOfRust: Cargo Workspaces, Installing Binaries & Custom Commands

Subesh Yadav — Mon, 04 Aug 2025 07:54:52 +0000

Welcome to Day 26! 🚀 Today was all about managing Rust projects more efficiently and expanding what Cargo can do for us. I explored:

Cargo Workspaces for managing multi-package projects
Installing binaries via cargo install
Extending Cargo using custom subcommands

Let’s break each of them down!

🧱 Cargo Workspaces

A workspace allows you to manage multiple related packages (crates) with a shared Cargo.lock and target directory.

✅ Why Workspaces?

Share dependencies efficiently
Compile shared code only once
Keep related crates organized

🔧 Creating a Workspace

Create root folder and Cargo.toml without [package]:

[workspace]
resolver = "3"
members = ["adder"]

Create a binary crate:

cargo new adder

This auto-adds adder to the members list.

Your file structure now looks like:

add/
├── Cargo.toml (workspace root)
├── adder/
│   └── src/main.rs
└── target/

➕ Adding More Crates

cargo new add_one --lib

Then update the workspace Cargo.toml:

members = ["adder", "add_one"]

In add_one/src/lib.rs:

pub fn add_one(x: i32) -> i32 {
    x + 1
}

And in adder/Cargo.toml:

[dependencies]
add_one = { path = "../add_one" }

🧪 Add a test in `add_one/src/lib.rs`

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

    #[test]
    fn it_works() {
        assert_eq!(add_one(2), 3);
    }
}

Build and test the whole workspace from root:

cargo build
cargo test

Run a specific crate:

cargo run -p adder
cargo test -p add_one

📦 Depending on External Crates

If you add a crate like rand to multiple crates in the workspace, Cargo ensures they use the same version and stores a single entry in the workspace-wide Cargo.lock.

# add_one/Cargo.toml
[dependencies]
rand = "0.8.5"

use rand; // You must actually use it or get a warning

To use rand in adder too, add it to its Cargo.toml. Dependencies are isolated per crate.

📦 Publishing Crates from Workspace

Each crate needs to be published separately using -p:

cargo publish -p add_one

🛠 Installing Binaries with `cargo install`

Use this to install Rust programs published to crates.io:

cargo install ripgrep

It installs the binary to $HOME/.cargo/bin, so make sure it’s in your $PATH.

Run it like any other binary:

rg --help

Only crates with binary targets (i.e., have a main.rs) can be installed this way.

🧩 Extending Cargo with Custom Commands

Cargo lets you define custom subcommands. If a binary is named cargo-something, you can invoke it with:

cargo something

For example, after installing a custom tool with cargo install, you can run it as if it were built-in:

cargo expand

Check all installed commands:

cargo --list

This extensibility makes Cargo incredibly flexible!

🧠 Summary

Workspaces simplify multi-crate projects
cargo install gives you access to tools like ripgrep, cargo-edit, etc.
Custom commands help extend your workflow

📌 Stay tuned as I continue my #100DaysOfRust journey. Follow me @SubeshDev for updates, and check out the full post on dev.to!

Day 25 of #100DaysOfRust: Customizing Builds and Publishing to Crates.io

Subesh Yadav — Mon, 04 Aug 2025 07:43:12 +0000

Welcome to Day 25 of my Rust journey! Today, I explored how to customize builds with release profiles and how to publish crates to crates.io, Rust’s official package registry. These topics are crucial when preparing a production-ready crate or sharing your project with the community.

🔧 Customizing Builds with Release Profiles

Rust provides predefined and customizable build profiles via Cargo, offering control over compile-time options.

Dev vs. Release Profiles

cargo build uses the dev profile (unoptimized + debug info)
cargo build --release uses the release profile (optimized)

$ cargo build
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s

$ cargo build --release
    Finished `release` profile [optimized] target(s) in 0.32s

Default Optimization Levels

# Cargo.toml
[profile.dev]
opt-level = 0

[profile.release]
opt-level = 3

opt-level ranges from 0 to 3.
Use lower levels for faster dev builds.
Use level 3 for optimized release builds.

Overriding Defaults

Customize profiles by overriding defaults in Cargo.toml:

[profile.dev]
opt-level = 1

Use Cargo’s documentation for full customization options.

📦 Publishing a Crate to Crates.io

Once your crate is ready, you can publish it for others to use via crates.io.

1️⃣ Document Your Code

Use documentation comments (///) with Markdown:

/// Adds one to the number given.
///
/// # Examples
/// 
/// let arg = 5;
/// let answer = my_crate::add_one(arg);
/// assert_eq!(6, answer);
/// 
pub fn add_one(x: i32) -> i32 {
    x + 1
}

Run:

cargo doc --open

To generate and view documentation.

Common Doc Sections

# Examples
# Panics
# Errors
# Safety

Doc Comments as Tests

Examples in /// comments are tested when running:

cargo test

Crate-Level Documentation

Use //! for crate-level or module-level descriptions:

//! # My Crate
//!
//! `my_crate` is a collection of utilities to simplify calculations.

📤 Setting Up Crates.io

1. Create an Account

2. Get API Token

Visit crates.io/me and copy your API key.
Authenticate locally:

cargo login

🧾 Add Metadata to Cargo.toml

Required fields:

[package]
name = "guessing_game"
version = "0.1.0"
edition = "2024"
description = "A fun game where you guess the number."
license = "MIT OR Apache-2.0"

SPDX License List for license identifiers.

🚀 Publishing the Crate

cargo publish

⚠️ Note: Publishing is permanent. You cannot delete a published version.

♻️ Publishing New Versions

Update the version in Cargo.toml:

version = "0.2.0"

Then publish:

cargo publish

Follow Semantic Versioning rules.

⛔ Yank Broken Versions

Prevent new projects from using a version:

cargo yank --vers 1.0.1

Undo a yank:

cargo yank --vers 1.0.1 --undo

🌍 Exporting Public API with `pub use`

Structure your public API without exposing internal module hierarchy:

// src/lib.rs
pub use self::kinds::PrimaryColor;
pub use self::utils::mix;

pub mod kinds {
    pub enum PrimaryColor {
        Red,
        Yellow,
        Blue,
    }
}

pub mod utils {
    use crate::kinds::*;
    pub fn mix(c1: PrimaryColor, c2: PrimaryColor) -> SecondaryColor {
        // ...
    }
}

Make it easier for consumers to import:

use art::PrimaryColor;
use art::mix;

🧠 Summary

Custom release profiles speed up dev and optimize releases.
Documentation is critical for crate usability.
Publishing requires proper metadata and account setup.
Crates.io is permanent—use yank to deprecate versions.
Use pub use to shape your public API.

Tomorrow, I’ll explore workspaces and managing multi-crate projects in Rust!

🚀 Follow me for more #100DaysOfRust progress and tips!

Day 24 of #100DaysOfRust: Loops vs Iterators & Zero-Cost Abstractions

Subesh Yadav — Mon, 04 Aug 2025 07:08:24 +0000

Welcome to Day 24! Today I explored how to choose between using loops or iterators in Rust and why iterators are preferred in most idiomatic code. I also learned about zero-cost abstractions, an important concept in systems programming that Rust excels at.

🔁 Choosing Between Loops or Iterators

At first glance, using a traditional for loop might feel more intuitive, especially if you’re coming from C-style or JavaScript programming. But Rust encourages using iterators for a cleaner and more expressive approach.

Why Iterators Are Preferred:

Focus on what needs to be done, not how.
Cleaner and more declarative.
Less boilerplate.
Easier to reason about complex chains of operations.

Iterators abstract away common loop mechanics and let you concentrate on the filtering, mapping, and reducing logic.

Think of iterators as the Rusty version of chaining methods in JavaScript: expressive, powerful, and composable.

⚖️ Comparing Performance: Loops vs Iterators

You might assume that lower-level for loops are faster than iterators—but here’s the truth:

Benchmark (searching for the word "the" in Sherlock Holmes):

test bench_search_for  ... bench:  19,620,300 ns/iter (+/- 915,700)
test bench_search_iter ... bench:  19,234,900 ns/iter (+/- 657,200)

🔍 The result? Almost identical performance.

This is because Rust’s iterators are zero-cost abstractions. The abstraction is stripped away during compilation, resulting in code that’s just as fast as hand-written loops.

🚀 What Are Zero-Cost Abstractions?

The term comes from C++ but is a core principle of Rust as well:

"What you don’t use, you don’t pay for. And what you do use, you couldn’t hand-write any better."

Rust compiles iterator chains to highly optimized machine code, often even better than what you’d write manually.

Here’s a great example from an audio decoder:

let buffer: &mut [i32];
let coefficients: [i64; 12];
let qlp_shift: i16;

for i in 12..buffer.len() {
    let prediction = coefficients.iter()
                                 .zip(&buffer[i - 12..i])
                                 .map(|(&c, &s)| c * s as i64)
                                 .sum::<i64>() >> qlp_shift;
    let delta = buffer[i];
    buffer[i] = prediction as i32 + delta;
}

Key Optimizations:

Loop unrolling: No overhead loop at runtime.
Register allocation: All coefficients live in CPU registers.
No bounds checks: Rust’s safety guarantees allow removal.

These all contribute to performance that’s nearly indistinguishable from (or better than) manual code.

🧠 Summary

Iterators express intent clearly and reduce boilerplate.
Performance of iterators and loops is nearly identical.
Rust’s zero-cost abstractions let you write expressive high-level code with low-level performance.
Don't fear iterators—embrace them!

That’s it for Day 24.

📢 Follow for more on my #100DaysOfRust journey!

Day 23 of #100DaysOfRust: Understanding Iterators in Rust

Subesh Yadav — Mon, 04 Aug 2025 06:50:39 +0000

Welcome to Day 23 of my #100DaysOfRust journey! Today was all about iterators — a fundamental and powerful feature of Rust. I explored their structure, behavior, and how to harness their power for cleaner, more efficient code.

🔁 What is the Iterator Pattern?

The iterator pattern lets you perform actions on a sequence of items one by one. In Rust, iterators are *lazy* — they don't do anything unless consumed.

let v1 = vec![1, 2, 3];
let v1_iter = v1.iter(); // Creates the iterator, but doesn't do anything yet

🔂 Using Iterators with `for` Loops

You can use iterators explicitly or implicitly. Here's an example:

let v1 = vec![1, 2, 3];
let v1_iter = v1.iter();

for val in v1_iter {
    println!("Got: {val}");
}

Rust hides the iteration logic under the hood, simplifying your code.

🧵 The `Iterator` Trait and `next()` Method

Rust defines the core behavior of iterators via the Iterator trait:

pub trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;
}

You can call next() to manually iterate:

let v1 = vec![1, 2, 3];
let mut v1_iter = v1.iter();

assert_eq!(v1_iter.next(), Some(&1));
assert_eq!(v1_iter.next(), Some(&2));
assert_eq!(v1_iter.next(), Some(&3));
assert_eq!(v1_iter.next(), None);

Note:

The iterator must be mutable.
iter() returns immutable references (&T).
Use into_iter() to take ownership.
Use iter_mut() for mutable references.

📥 Consuming Adaptors (e.g., `sum`)

These methods consume the iterator. For example:

let v1 = vec![1, 2, 3];
let v1_iter = v1.iter();
let total: i32 = v1_iter.sum();

assert_eq!(total, 6);

You can't reuse the iterator after a consuming method like sum.

🧪 Iterator Adapters (e.g., `map`)

These are lazy and return new iterators instead of consuming the current one.

let v1: Vec<i32> = vec![1, 2, 3];
let v2: Vec<_> = v1.iter().map(|x| x + 1).collect();

assert_eq!(v2, vec![2, 3, 4]);

The above transforms each value but doesn’t execute until collect() is called.

🔍 Using `filter()` with Captured Environment

Closures passed to iterator adapters can capture their environment:

#[derive(Debug, PartialEq)]
struct Shoe {
    size: u32,
    style: String,
}

fn shoes_in_size(shoes: Vec<Shoe>, shoe_size: u32) -> Vec<Shoe> {
    shoes.into_iter().filter(|s| s.size == shoe_size).collect()
}

Closures here access the external shoe_size variable.

🔧 Refactoring with Iterators

You can replace imperative logic with iterators to simplify code.

Before:

pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
    let mut results = Vec::new();
    for line in contents.lines() {
        if line.contains(query) {
            results.push(line);
        }
    }
    results
}

After:

pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
    contents
        .lines()
        .filter(|line| line.contains(query))
        .collect()
}

So much cleaner and more concise!

🔄 Replacing `clone` with Iterator

We can reduce inefficient clone() usage by changing a method to accept an iterator:

impl Config {
    pub fn build(
        mut args: impl Iterator<Item = String>,
    ) -> Result<Config, &'static str> {
        args.next(); // skip program name

        let query = args.next().ok_or("Missing query")?;
        let file_path = args.next().ok_or("Missing file path")?;

        let ignore_case = env::var("IGNORE_CASE").is_ok();

        Ok(Config { query, file_path, ignore_case })
    }
}

This makes the function more idiomatic and avoids unnecessary allocations.

🧠 Summary

Iterators in Rust are lazy and only do work when consumed.
The Iterator trait defines the next() method.
You can consume iterators (sum, collect) or adapt them (map, filter).
Closures passed to adapters can capture external state.
Iterators enable concise, declarative, and safe data processing.

That’s all for Day 23! 🚀
Iterators are at the heart of idiomatic Rust.

🔔 Follow me for the rest of my journey at @subesh_dev!

Day 22 of #100DaysOfRust: Closures in Rust

Subesh Yadav — Mon, 04 Aug 2025 05:31:47 +0000

Today, I took a deep dive into closures in Rust. These are powerful, flexible constructs that enable functional-style programming and can be used to make code more concise and expressive. Here's everything I explored today:

🧠 What Are Closures?

Closures are anonymous functions that can capture values from their environment. They can be saved into variables, passed to functions, or returned from them.

They differ from regular functions in key ways:

Can capture from the surrounding scope.
Type inference for parameters and return values.
Can implement Fn traits depending on how they use captured values.

📦 Capturing the Environment

Closures can capture variables from their scope:

#[derive(Debug, PartialEq, Copy, Clone)]
enum ShirtColor {
    Red,
    Blue,
}

struct Inventory {
    shirts: Vec<ShirtColor>,
}

impl Inventory {
    fn giveaway(&self, user_preference: Option<ShirtColor>) -> ShirtColor {
        user_preference.unwrap_or_else(|| self.most_stocked())
    }

    fn most_stocked(&self) -> ShirtColor {
        let (mut red, mut blue) = (0, 0);
        for color in &self.shirts {
            match color {
                ShirtColor::Red => red += 1,
                ShirtColor::Blue => blue += 1,
            }
        }
        if red > blue { ShirtColor::Red } else { ShirtColor::Blue }
    }
}

fn main() {
    let store = Inventory {
        shirts: vec![ShirtColor::Blue, ShirtColor::Red, ShirtColor::Blue],
    };

    let pref1 = Some(ShirtColor::Red);
    let pref2 = None;

    println!("User 1 gets {:?}", store.giveaway(pref1));
    println!("User 2 gets {:?}", store.giveaway(pref2));
}

This uses a closure inside unwrap_or_else() that captures self.

✍ Closure Syntax and Type Inference

Closures are concise and types are often inferred:

fn add_fn(x: u32) -> u32 { x + 1 }
let add_closure1 = |x: u32| -> u32 { x + 1 };
let add_closure2 = |x| { x + 1 };
let add_closure3 = |x| x + 1;

Rust infers parameter and return types based on context. However, closures can only use one inferred type per invocation.

let example = |x| x;
let a = example(String::from("hello"));
let b = example(5); // ❌ ERROR: mismatched types

🔄 Borrowing, Mutability, and Moving

Closures can capture by:

Immutable borrow
Mutable borrow
Move (ownership)

let list = vec![1, 2, 3];
let print_list = || println!("{list:?}");

let mut list = vec![1, 2, 3];
let mut modify_list = || list.push(4);
modify_list();

let list = vec![1, 2, 3];
thread::spawn(move || println!("From thread: {list:?}"))
    .join()
    .unwrap();

🧬 Fn, FnMut, FnOnce Traits

Closures implement one or more traits depending on how they use the environment:

FnOnce: Can be called once. Moves values.
FnMut: Mutates but doesn’t move.
Fn: Does not mutate or move. Callable multiple times.

Example: `unwrap_or_else`

impl<T> Option<T> {
    pub fn unwrap_or_else<F>(self, f: F) -> T
    where F: FnOnce() -> T {
        match self {
            Some(x) => x,
            None => f(),
        }
    }
}

f is called at most once — hence FnOnce is required.

Example: `sort_by_key`

list.sort_by_key(|r| r.width);

Requires FnMut because the closure runs multiple times.

❌ Using FnOnce Where FnMut Is Needed

This code won’t compile:

let value = String::from("captured");
list.sort_by_key(|r| {
    sort_operations.push(value); // ❌ Moves value
    r.width
});

Instead, capture mutable reference:

let mut counter = 0;
list.sort_by_key(|r| {
    counter += 1;
    r.width
});

✅ Summary

Closures are powerful tools for functional-style programming.
Can capture variables by reference, mutable reference, or move.
Type inference makes them concise.
Trait bounds (Fn, FnMut, FnOnce) define closure capabilities.
Useful in APIs like unwrap_or_else, sort_by_key, threading, etc.

Tomorrow, I’ll explore iterators — another key functional concept in Rust.

🚀 Follow me for more on my #100DaysOfRust journey!

Day 21 of #100DaysOfRust: Organizing and Running Tests in Rust

Subesh Yadav — Wed, 30 Jul 2025 17:12:09 +0000

Welcome to Day 21 of my Rust journey! Today, I delved deep into the mechanisms Rust provides for organizing and running tests. Yesterday, I explored writing test functions and macros like assert!, assert_eq!, and assert_ne!. Today was about running those tests efficiently, filtering and organizing them, and understanding the distinctions between unit and integration tests.

🧪 How Rust Runs Tests

Rust’s cargo test command compiles your code in test mode and runs the resultant test binary. By default, it:

Runs all tests in parallel using threads.
Captures output of passing tests for a cleaner report.

You can customize this behavior using:

cargo test --help: View Cargo’s test options.
cargo test -- --help: View options passed to the test binary.

🧵 Running Tests in Parallel or Consecutively

Rust runs tests in parallel by default to speed up feedback. But this can cause issues if tests share state (e.g., the same file, directory, environment variables).

Avoid shared state or use:

cargo test -- --test-threads=1

This command disables parallelism and runs tests serially.

👁 Showing Output for Passing Tests

By default, output (println!) in passing tests is hidden.

To view it:

cargo test -- --show-output

Example

fn prints_and_returns_10(a: i32) -> i32 {
    println!("I got the value {a}");
    10
}

#[test]
fn this_test_will_pass() {
    let value = prints_and_returns_10(4);
    assert_eq!(value, 10);
}

Use --show-output to view the printed output.

🎯 Running a Subset of Tests by Name

You don’t have to run all tests.

Run a single test:

cargo test one_hundred

Example:

#[test]
fn one_hundred() {
    assert_eq!(100, 10 * 10);
}

Run tests with partial name match:

cargo test add

This runs all tests with add in the name.

Example:

#[test]
fn add_two_numbers() {
    assert_eq!(2 + 2, 4);
}

#[test]
fn add_three_numbers() {
    assert_eq!(1 + 2 + 3, 6);
}

🔕 Ignoring Expensive Tests

You can ignore long-running tests by default and run them only when needed.

#[test]
#[ignore]
fn expensive_test() {
    // takes time
}

Run ignored tests only:

cargo test -- --ignored

Run all tests including ignored:

cargo test -- --include-ignored

🗂 Test Organization: Unit Tests vs Integration Tests

🧪 Unit Tests

Placed inside src/ next to the code.
Use #[cfg(test)] to compile only during testing.
Access private items.

// src/lib.rs
pub fn add(x: u32, y: u32) -> u32 {
    x + y
}

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

    #[test]
    fn it_works() {
        assert_eq!(add(2, 2), 4);
    }
}

🧩 Integration Tests

Placed in tests/ directory.
Compiled as separate crates.
Only access public API.

Example:

// tests/integration_test.rs
use my_crate::add;

#[test]
fn it_adds_two() {
    assert_eq!(add(2, 2), 4);
}

🧱 Shared Setup for Integration Tests

Put reusable code in tests/common/mod.rs:

// tests/common/mod.rs
pub fn setup() {
    // Setup code here
}

Use it like this:

mod common;

#[test]
fn it_adds_two() {
    common::setup();
    assert_eq!(add(2, 2), 4);
}

🧠 Summary

Rust allows parallel and serial test execution.
Use filtering to speed up your workflow.
Structure matters: unit vs integration.
Output visibility, ignored tests, and subsetting are all customizable.
Integration tests live in their own crates under tests/.

That’s all for today.

🧪 Day 20 of #100DaysOfRust: Writing Tests in Rust 🦀

Subesh Yadav — Wed, 30 Jul 2025 16:37:43 +0000

Hello, Rustaceans!
Today marks Day 20 of my #100DaysOfRust journey, and I dove into a key feature of Rust that ensures correctness and reliability — writing tests.

Rust has built-in support for testing with cargo test, and it provides excellent macros, attributes, and tools for writing clear, expressive, and robust test cases.

🧪 Anatomy of a Test Function

Every test function in Rust is marked with the #[test] attribute.

A basic test function:

#[test]
fn it_works() {
    // 1. Set up any needed data or state.
    let a = 2;

    // 2. Run the code you want to test.
    let b = a + 2;

    // 3. Assert that the result is what you expect.
    assert_eq!(b, 4);
}

✅ Running Tests

Use this command to run all tests:

cargo test

Rust compiles the tests in a separate test binary and shows clear output about passing or failing tests.

✔️ Checking Conditions with `assert!`

The assert! macro ensures that a boolean condition is true. If it's not, the test fails.

#[test]
fn assert_macro_example() {
    let value = true;
    assert!(value); // Passes
}

Fails if:

assert!(false); // panics with default message

You can also add a custom failure message:

assert!(1 + 1 == 3, "Math is broken!");

🧮 Testing Equality with `assert_eq!` and `assert_ne!`

Rust provides macros to compare values:

assert_eq!(a, b) — passes if a == b
assert_ne!(a, b) — passes if a != b

#[test]
fn test_equality_macros() {
    assert_eq!(2 + 2, 4);
    assert_ne!(5, 3);
}

When these fail, Rust shows both the expected and actual values, making debugging easier.

💬 Custom Failure Messages

You can also include custom messages in these macros:

#[test]
fn custom_message_example() {
    let result = 2 + 2;
    assert_eq!(result, 5, "Expected 5 but got {}", result);
}

Output:

thread 'main' panicked at 'Expected 5 but got 4', src/main.rs:4:5

💥 Testing for Panics with `#[should_panic]`

Some tests are expected to panic (i.e., crash intentionally under specific conditions).

Use the #[should_panic] attribute:

#[test]
#[should_panic]
fn panics_when_called() {
    panic!("This function panics!");
}

Make it more precise using expected:

#[test]
#[should_panic(expected = "Guess value must be less than or equal to 100")]
fn panic_with_message() {
    panic!("Guess value must be less than or equal to 100");
}

🎯 Writing Tests That Return `Result<T, E>`

Rust lets you write tests that return Result<(), E> for clearer error reporting.

#[test]
fn test_with_result() -> Result<(), String> {
    let value = 2 + 2;

    if value == 4 {
        Ok(())
    } else {
        Err("2 + 2 did not equal 4".into())
    }
}

This lets you use ? inside your tests, which is especially useful when testing functions that return Result.

🧪 Summary

Concept	Description
`#[test]`	Marks a function as a unit test
`assert!`, `assert_eq!`, `assert_ne!`	Macros to validate test conditions
`#[should_panic]`	Use when a function should panic
`Result<(), E>` return type	Clean test error reporting and `?` usage
Custom messages	Improve failure debugging

🗕️ What’s Next?

In Day 21, I’ll explore how to organize tests, including modules, integration tests, test hierarchies, and best practices.

Let me know your favorite testing tip in Rust!
Until tomorrow, happy coding! 🦀

🌱 Day 19 of #100DaysOfRust: Understanding Lifetimes in Rust

Subesh Yadav — Tue, 29 Jul 2025 14:16:26 +0000

Today’s Focus: Lifetimes – a unique and powerful concept in Rust that ensures memory safety without needing a garbage collector.

✅ What are Lifetimes?

Lifetimes are a kind of generic used by Rust to ensure references are valid for as long as they need to be. They prevent dangling references and make memory safety possible at compile time.

Think of lifetimes as a promise that references will not outlive the data they point to.

🔍 Why Lifetimes?

Every reference in Rust has a lifetime, but most of the time, the compiler can infer them. However, when it can’t, we need to annotate them explicitly to let the compiler understand how long references should be valid.

📌 Example of a Dangling Reference (Does not compile):

fn main() {
    let r;
    {
        let x = 5;
        r = &x;
    }
    println!("r: {}", r); // ❌ x is dropped, r points to invalid memory
}

✅ Fixed Version:

fn main() {
    let x = 5;
    let r = &x;
    println!("r: {}", r);
}

🧠 The Borrow Checker

Rust’s borrow checker compares lifetimes to ensure references don’t outlive the data they point to. It’s what catches the issue in the first example.

🧪 Lifetimes in Functions

We might write a function like this:

fn longest(x: &str, y: &str) -> &str {
    if x.len() > y.len() { x } else { y }
}

But this won't compile. Rust needs to know how the lifetimes of x and y relate to the returned reference.

✅ Correct Version with Lifetime Annotations:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

This means the returned reference will live as long as the shortest of the two inputs.

🔧 Lifetime Syntax

&i32 → reference
&'a i32 → reference with explicit lifetime 'a
&'a mut i32 → mutable reference with explicit lifetime 'a

🧪 Real Example:

fn main() {
    let string1 = String::from("abcd");
    let string2 = "xyz";
    let result = longest(string1.as_str(), string2);
    println!("The longest string is {}", result);
}

⛔ A Non-Compiling Example

fn main() {
    let string1 = String::from("abcd");
    let result;
    {
        let string2 = String::from("xyz");
        result = longest(string1.as_str(), string2.as_str());
    }
    println!("The longest string is {}", result); // ❌ string2 is dropped
}

🧪 Experiment Yourself

Try variations: change lifetimes, scope of variables, and return values. Test how Rust behaves. You'll learn by doing.

📦 Lifetimes in Structs

struct ImportantExcerpt<'a> {
    part: &'a str,
}

This ensures the struct doesn’t outlive the reference it holds.

🧵 Lifetime Elision Rules

Rust tries to infer lifetimes using three rules:

Each parameter gets its own lifetime.
If there is one input lifetime, it’s assigned to all output lifetimes.
If multiple input lifetimes exist and one is &self, its lifetime is assigned to the output.

These rules help reduce the need for manual annotations in many cases.

🧪 Example Using Rule 3 (Methods):

impl<'a> ImportantExcerpt<'a> {
    fn announce_and_return_part(&self, announcement: &str) -> &str {
        println!("Attention please: {}", announcement);
        self.part
    }
}

🧊 'static Lifetime

let s: &'static str = "I have a static lifetime.";

Means the data lives for the entire duration of the program. Common with string literals.

🧬 Combining Generics, Trait Bounds, and Lifetimes

use std::fmt::Display;

fn longest_with_an_announcement<'a, T>(
    x: &'a str,
    y: &'a str,
    ann: T,
) -> &'a str
where
    T: Display,
{
    println!("Announcement! {}", ann);
    if x.len() > y.len() { x } else { y }
}

🧠 Summary

Lifetimes prevent dangling references.
They're enforced at compile time via the borrow checker.
Most of the time, lifetimes are inferred, but sometimes we need to annotate them.
You can even use them in structs, functions, methods, and with traits and generics.
This enables Rust to stay fast and safe without a garbage collector.

🔗 Next Up: Writing tests in Rust!

📚 Stay curious, stay consistent!

Forem: Subesh Yadav

Day 30 of #100DaysOfRust: Reference Counting with Rc

🔄 Why Rc?

📝 Example: Shared Ownership in Lists

✅ Fixing with Rc

📊 Tracking Reference Counts

Output:

🚫 Why Rc Only Allows Immutable References

🧠 Summary

Day 29 of #100DaysOfRust: The Drop Trait and Resource Cleanup

🧹 What is the Drop Trait?

🛠 Example: Custom Smart Pointer with Drop

Output:

🚫 You Can’t Call Drop Directly

✅ Forcing Early Drop with std::mem::drop

Output:

💡 Why Drop Matters

🧠 Key Takeaways

Day 28 of #100DaysOfRust: Smart Pointers and Deref Coercion

📌 Following References to Values

📦 Using Box Like a Reference

🛠 Defining Our Own Smart Pointer

🔗 Implementing the Deref Trait

🔄 Implicit Deref Coercions

🔐 Deref and Mutability

🧠 Summary

Day 27 of #100DaysOfRust: Introduction to Smart Pointers in Rust

🔹 What Are Smart Pointers?

📦 Using Box to Point to Data on the Heap

When to Use Box:

Example: Storing Data on the Heap

🔁 Enabling Recursive Types with Boxes

First Attempt (Does Not Compile)

Fixing with Box

Why This Works

🧠 Key Takeaways

Day 26 of #100DaysOfRust: Cargo Workspaces, Installing Binaries & Custom Commands

🧱 Cargo Workspaces

✅ Why Workspaces?

🔧 Creating a Workspace

➕ Adding More Crates

🧪 Add a test in add_one/src/lib.rs

📦 Depending on External Crates

📦 Publishing Crates from Workspace

🛠 Installing Binaries with cargo install

🧩 Extending Cargo with Custom Commands

🧠 Summary

Day 25 of #100DaysOfRust: Customizing Builds and Publishing to Crates.io

🔧 Customizing Builds with Release Profiles

Dev vs. Release Profiles

Default Optimization Levels

Overriding Defaults

📦 Publishing a Crate to Crates.io

1️⃣ Document Your Code

Common Doc Sections

Doc Comments as Tests

Crate-Level Documentation

📤 Setting Up Crates.io

1. Create an Account

2. Get API Token

🧾 Add Metadata to Cargo.toml

🚀 Publishing the Crate

♻️ Publishing New Versions

⛔ Yank Broken Versions

🌍 Exporting Public API with pub use

🧠 Summary

Day 24 of #100DaysOfRust: Loops vs Iterators & Zero-Cost Abstractions

🔁 Choosing Between Loops or Iterators

Why Iterators Are Preferred:

⚖️ Comparing Performance: Loops vs Iterators

🚀 What Are Zero-Cost Abstractions?

Key Optimizations:

🧠 Summary

Day 23 of #100DaysOfRust: Understanding Iterators in Rust

🔁 What is the Iterator Pattern?

🔂 Using Iterators with for Loops

🧵 The Iterator Trait and next() Method

📥 Consuming Adaptors (e.g., sum)

🧪 Iterator Adapters (e.g., map)

🔍 Using filter() with Captured Environment

✅ Forcing Early Drop with `std::mem::drop`

🧪 Add a test in `add_one/src/lib.rs`

🛠 Installing Binaries with `cargo install`

🌍 Exporting Public API with `pub use`

🔂 Using Iterators with `for` Loops

🧵 The `Iterator` Trait and `next()` Method

📥 Consuming Adaptors (e.g., `sum`)

🧪 Iterator Adapters (e.g., `map`)

🔍 Using `filter()` with Captured Environment

🔄 Replacing `clone` with Iterator

Example: `unwrap_or_else`

Example: `sort_by_key`

✔️ Checking Conditions with `assert!`

🧮 Testing Equality with `assert_eq!` and `assert_ne!`

💥 Testing for Panics with `#[should_panic]`

🎯 Writing Tests That Return `Result<T, E>`