Rust Iterators and Closures: The Power Combo

TL;DR: Iterators are lazy. Closures are anonymous functions with captured state. Combined, they outperform manual loops.

The short version

Iterators are lazy. Closures are anonymous functions with captured state. Combined, they outperform manual loops.

This guide covers the mental model, the patterns that pay off, and the trade-offs that decide whether a technique fits your code.

Working example

Here's a minimal example you can run as-is. Drop it in a fresh file, run it, and trace through it once before reading the rest.

use std::collections::HashMap;

fn word_count(text: &str) -> HashMap<&str, u32> {
    let mut counts = HashMap::new();
    for word in text.split_whitespace() {
        *counts.entry(word).or_insert(0) += 1;
    }
    counts
}

fn main() {
    let text = "the quick brown fox the lazy dog";
    let counts = word_count(text);
    println!("{:?}", counts);
}

Why this pattern

The shape above shows up in real Rust codebases because it satisfies three constraints at once: it stays type-safe, it composes with the rest of the language's idioms, and it leaves a clear trail for the next developer (which, in six months, is you).

When you write the same pattern three times in a project, extract it. When you write it three times across projects, extract it into a shared library.

A common variant

The same idea adapted for a different shape. Notice how the structure stays the same — only the specifics change.

use std::fs;
use std::io;

fn read_config(path: &str) -> io::Result<String> {
    let raw = fs::read_to_string(path)?;
    Ok(raw.trim().to_string())
}

fn main() {
    match read_config("config.toml") {
        Ok(s) => println!("{}", s),
        Err(e) => eprintln!("error: {}", e),
    }
}

Trade-offs to watch

Every pattern has a failure mode. The most common one here is over-application: developers who learn a technique apply it everywhere, including places where simpler code would have been clearer.

Rule of thumb: if the abstraction takes more lines to describe than it saves, the abstraction is wrong.

A more involved example

Once the basic pattern is clear, here's how it composes with surrounding code. Read this one slowly.

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

struct User { name: String }

impl Greet for User {
    fn hello(&self) -> String {
        format!("hi, {}", self.name)
    }
}

fn main() {
    let u = User { name: "ada".into() };
    println!("{}", u.hello());
}

When to skip it

If the surrounding code is already simple, don't reach for Rust-specific cleverness. Boring code is a feature. Save the patterns for places where they actually pay off — usually at module boundaries, in shared libraries, or where the alternative would be 50 lines of repetition.

FAQ

Related reading

• Rust Errors: Result vs anyhow vs thiserror
• Rust Lifetimes, Finally Explained
• Async Rust with Tokio: The Fundamentals
• The context Package: A Deep Dive
• Server Components: The Trade-offs Nobody Mentions