$ cat table_of_contents.txt

Why I Made This Reference

Rust itself comes with an excellent toolchain, but the ecosystem surrounding it is enormous.

While watching the My 2026 Rust Toolkit video from No Boilerplate, I quickly realized that simply hearing the names of all these tools wasn’t enough. There were terminal utilities, Cargo extensions, testing tools, editor choices, error-handling libraries, parallel-processing libraries, web frameworks, database tools, and frontend frameworks.

Trying to remember all of that after one viewing wasn’t going to happen.

So rather than treating the video as a shopping list, I went through it piece by piece, tested several of the tools on my Debian system, and tried to understand why I might actually want each one.

This post is my reference for later.

Part 1 — Development Tools

Clippy — Rust’s Linter

Clippy analyzes Rust code and catches suspicious, inefficient, confusing, or non-idiomatic patterns.

The normal command is:

cargo clippy

The video demonstrated a much stricter Clippy configuration using groups such as:

[lints.clippy]
pedantic = { level = "deny", priority = -1 }
nursery = { level = "deny", priority = -1 }

along with individual rules such as:

unwrap_used = "deny"
expect_used = "deny"
indexing_slicing = "deny"
panic = "deny"
todo = "deny"

The lesson for me wasn’t necessarily to copy this configuration immediately.

It was to understand that Clippy can be tuned from friendly advisor to extremely strict gatekeeper.

For now, ordinary cargo clippy is plenty useful.

A compiler lesson worth remembering

Another useful point from the video:

The first error appearing in the source file isn’t necessarily the first error I should fix. The first meaningful error in the compiler output often is.

One underlying problem can cause several cascading compiler errors.

Fix the first real compiler error, compile again, and several of the others may disappear.

Bacon — Continuous Rust Checking

Bacon was one of the tools I decided to install.

Instead of repeatedly typing:

cargo check

I can run:

bacon

Bacon watches the project and automatically checks it whenever files change.

I tested it directly against my existing Burn project.

Bacon immediately detected the project and displayed:

burn-demo | check | 1 warning

The warning wasn’t from my program. It came from Burn dependencies containing code Rust warns could become incompatible with a future Rust version.

That was actually a perfect first Bacon demonstration.

My workflow can now look like:

Edit Rust
    ↓
Save
    ↓
Bacon detects change
    ↓
Cargo checks project
    ↓
Errors/warnings appear
    ↓
Fix and save again

No constantly retyping cargo check.

cargo-nextest — A Serious Test Runner

I also installed:

cargo install --locked cargo-nextest

My installed version was:

cargo-nextest v0.9.143

The normal command is:

cargo nextest run

Nextest isn’t simply “cargo test, but faster.”

It provides a much more sophisticated test-running environment, including facilities for handling slow tests, retries, test filtering and partitioning, serial execution requirements, rerunning failures, CI-oriented workflows, and integration with broader debugging, coverage, tracing, and mutation-testing workflows.

The video describes it as capable of being up to three times faster than cargo test, depending on the workload.

I tested it against burn-demo:

Starting 0 tests across 1 binary
Summary ... 0 tests run
error: no tests to run

Perfect.

Nextest worked.

My Burn demo simply doesn’t have any tests yet.

That’s an important distinction:

cargo test / nextest
        ↓
Is my program correct?

Criterion / benchmarks
        ↓
How fast is my program?

cargo-seek — Exploring the Crate Ecosystem

This one already earned its own article.

Instead of repeatedly jumping between a browser, crates.io, documentation pages, and Cargo commands, cargo-seek gives me an interactive terminal interface for exploring Rust crates.

I tested it by searching for:

burn

and immediately saw the Burn ecosystem, including crates related to tensors, training, WGPU, CUDA, neural networks, and other components.

It turned crate discovery into something much more visual.

cargo-generate — Project Scaffolding

Normal Cargo can create a simple project:

cargo new my-project

But larger applications need considerably more structure.

That’s where cargo-generate comes in.

It can take an existing project template—often from a Git repository—and generate an entire starting project.

I tested it with:

cargo generate leptos-rs/start-trunk

It successfully found:

https://github.com/leptos-rs/start-trunk.git

and prompted me for:

Project Name:

I canceled there because I didn’t actually need another Leptos application.

But the experiment proved that cargo-generate was working.

Watchexec

Watchexec evolves the basic file-watcher idea into something much more general.

It can watch files or directories and trigger arbitrary commands when something changes.

For example, a workflow could potentially become:

Save
 ↓
cargo clippy
 ↓
cargo test
 ↓
cargo run

This overlaps somewhat with Bacon, but there’s an important distinction.

Bacon is Rust-oriented. Watchexec is general-purpose.

For now, Bacon covers most of what I need.

Watchexec goes on the interesting for later list.

Editors: Neovim, LazyVim, Helix, VS Code and Zed

The creator uses Neovim with LazyVim as his primary environment, while also mentioning Helix, VS Code, and Zed.

The important statement in the video was:

“There are many editors, but this one is mine.”

That’s the right way to look at editors.

I already use Zed, so there’s no reason for me to replace a working development environment simply to duplicate someone else’s toolkit.

Neovim and LazyVim remain interesting things I could explore later.

Part 2 — A Personal Rust “Standard Library”

The video then shifts from programs installed on the machine to crates used inside Rust projects.

That’s an important distinction.

A tool might be installed with:

cargo install ...

A library used by my program is normally added with:

cargo add ...

Those aren’t the same thing.

Rust Error Handling

Rust makes failure explicit through:

Result<T, E>

and absence explicit through:

Option<T>

Rather than hiding these conditions, Rust makes them part of the type system.

But defining and carrying elaborate error types everywhere can become cumbersome.

That leads to several popular crates.

anyhow

A widely used approach to ergonomic application-level errors.

eyre

Another flexible error-reporting library.

color-eyre

Builds on that approach with much richer, human-friendly terminal error reports.

This is one I’ll remember for future command-line applications.

Iterator Utilities

Rust encourages expressing data transformations through iterator pipelines:

data
 ↓
iter
 ↓
filter
 ↓
map
 ↓
collect

This produces expressive code while still allowing the compiler to optimize aggressively.

That led into one of the video’s recurring themes:

Zero-Cost Abstractions

High-level Rust doesn’t automatically mean expensive Rust.

Iterator chains can often compile down to efficient machine code comparable to the loops and conditionals I might otherwise write manually.

I can write expressive abstractions without necessarily paying for layers of runtime machinery.

Criterion — Benchmarking

Tests answer:

Does it work?

Benchmarks answer:

How fast does it work?

Criterion provides sophisticated benchmarking with repeated measurements, statistical analysis and report generation.

Instead of trusting a single stopwatch measurement, Criterion can help determine whether an optimization actually improved performance.

That’s a lesson worth remembering:

Don’t guess about performance. Measure it.

Rayon — Parallelism Without the Pain

Rayon is particularly interesting.

I had actually already added it to my Burn project:

rayon = "1.12.0"

It’s located in:

~/Projects/burn-demo/Cargo.toml

Rayon makes CPU data parallelism remarkably approachable.

A normal iterator might use:

.iter()

while an appropriate parallel workload can use:

.par_iter()

Conceptually:

Sequential

A → B → C → D


Parallel

       ┌→ A
input ─┼→ B
       ├→ C
       └→ D

Rayon is especially interesting for CPU-bound workloads.

That doesn’t mean async frameworks are useless. Network servers, HTTP requests and other I/O-heavy workloads present a different problem.

The important lesson is:

Don’t automatically reach for async when the problem is really CPU parallelism.

Part 3 — Go-To Crates

Then came crates the creator reaches for in many real applications.

Serde

This is one of the biggest names in Rust.

Serde handles serialization and deserialization.

Conceptually:

Rust struct
    ↓
serialize
    ↓
JSON / other format
    ↓
deserialize
    ↓
Rust struct

A typical structure might look like:

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct Point {
    x: i32,
    y: i32,
}

Even when a Rust application doesn’t use Serde directly, one of its dependencies very well might.

Verdict: essential knowledge.

Time: Jiff and Chrono

Rust’s standard library provides time-related foundations, but dedicated crates make real-world date and time handling easier.

The video mentions:

Jiff and Chrono.

I don’t need either until I have a project involving serious date/time manipulation, but they’re names worth remembering.

Clap — Command-Line Applications

Rust provides access to command-line arguments, but Clap turns argument parsing into a much richer experience.

With its derive functionality, command-line arguments can be modeled as Rust structures while help information and parsing behavior are generated around them.

This is something I’ll definitely want when I start creating more substantial Rust CLI programs.

The video also gives bpaf an honorable mention as an alternative.

command-run

Rust’s standard process APIs are comprehensive but relatively low-level.

The command-run crate provides a higher-level approach for running external commands and working with their output.

Not something I need every day, but useful to know exists.

utoipa — Self-Documenting APIs

utoipa connects Rust web APIs with OpenAPI documentation.

It supports popular Rust web frameworks and allows types and endpoint information to participate in generating API specifications.

This becomes particularly interesting alongside Axum.

A future backend stack could look something like:

Axum
  │
utoipa
  │
OpenAPI documentation

reqwest — HTTP Client

reqwest is a major Rust HTTP client.

It’s what I might reach for when my Rust program needs to communicate with an HTTP API.

It provides async and blocking APIs and can operate with Rust-native TLS support.

This one belongs firmly on the learn when needed list.

SQLx — Databases

SQLx provides asynchronous database access for Rust and supports databases including PostgreSQL, MySQL and SQLite.

One particularly attractive feature is its support for checking SQL queries against database information, catching certain query problems much earlier than runtime.

The accompanying SQLx CLI can help with tasks such as migrations and offline query metadata workflows.

This one becomes particularly interesting when combined with Axum:

HTTP request
     ↓
    Axum
     ↓
business logic
     ↓
    SQLx
     ↓
 PostgreSQL

Leptos — Rust on the Frontend

This was a fun moment because Leptos wasn’t theoretical for me.

I’ve already created and run a Leptos application on this machine, including a reactive counter and hot-reloading development workflow.

Leptos can support client-side applications as well as server-side/full-stack approaches.

The video’s creator prefers it primarily for frontend work.

My own experience with it is only beginning, so I’ll form my own opinion as I continue learning.

Trunk — Rust/WASM Web Tooling

Trunk provides development and bundling tools for Rust WebAssembly applications.

Its role includes handling web assets and providing a convenient development workflow around Rust/WASM applications.

It fits naturally beside frameworks such as Leptos.

Dioxus

Dioxus is another Rust UI framework with ambitions beyond browser-only applications.

It can target multiple application environments, making it particularly interesting for developers wanting to share Rust UI concepts across web, desktop and mobile.

I’m not switching away from Leptos just to collect frameworks, but Dioxus is worth remembering.

Tauri

Tauri approaches desktop/mobile application development differently.

It allows web-based frontend technologies to work with a Rust application core while using native system webviews rather than simply shipping the traditional full Electron-style browser runtime.

Another tool for the future—not something I need to install merely because I heard about it.

What I Actually Learned

The biggest lesson from this video wasn’t:

“Install all these Rust things.”

It was:

Understand what layer each tool belongs to.

My mental map now looks like this:

                  MY RUST TOOLKIT

DEVELOPMENT
├── Cargo
├── Clippy
├── Bacon
├── cargo-nextest
├── cargo-seek
└── cargo-generate

EDITOR
└── Zed

ERROR HANDLING
├── anyhow
├── eyre
└── color-eyre

DATA
├── Serde
└── iterator utilities

PERFORMANCE
├── Criterion
└── Rayon

CLI
├── Clap
├── bpaf
└── command-run

BACKEND / API
├── Axum
├── utoipa
├── reqwest
└── rustls

DATABASE
└── SQLx

WEB / UI
├── Leptos
├── Trunk
├── Dioxus
└── Tauri

AI / DEEP LEARNING
└── Burn

And that’s a much more useful way for me to remember it.

My Current Status

I don’t need every tool in the video installed.

Some are already part of my environment. Some belong inside individual projects. Others are simply names I now recognize for when the appropriate problem appears.

That’s exactly what I wanted from this exercise.

I’m not trying to duplicate somebody else’s development environment.

I’m slowly building my own Rust toolkit.

And the next time I can’t remember what Bacon does, why Nextest exists, what Rayon is for, or which crate handles serialization, I won’t need to watch the entire video again.

I’ll come back here.