Tris Oaten's 2026 Rust Development Toolkit

There's a particular kind of developer video that isn't really a tutorial. It's closer to a map—someone drawing the territory they've already walked, for people who are about to. Tris Oaten's My 2026 Rust Toolkit on the No Boilerplate channel falls squarely into that category: a brisk, opinionated walkthrough of roughly a dozen tools and crates that Oaten reaches for in every Rust project, bundled with the config defaults that make them actually useful.

It's worth reading as a document not just of what to install, but of how an experienced Rust developer has come to think about their environment.

The Environment Question

Oaten opens with devenv—a tool built on top of Nix that offers per-project environment isolation without the overhead of containers. The pitch is a single config file, checked into your repo, that specifies your Rust version (nightly, in his case), your system packages, your pre-commit hooks, and even auto-run scripts. Your colleagues clone the repo, run devenv, and get an identical environment. No "works on my machine." No Docker daemon eating RAM.

His framing here is candid: "Not everyone is powerful enough to use Nix. I know I wasn't for many years, but there is a gateway drug available in devenv." He's acknowledging that the Nix ecosystem, for all its reproducibility guarantees, has a steepness to it that has deterred a lot of developers who might otherwise benefit. Devenv tries to smooth that onramp.

The interesting tension here is one Oaten identifies himself: devenv isn't Nix. You can do everything devenv does with pure Nix—and then some—but you can't do it as simply. That's not a knock on devenv; it's a legitimate design tradeoff. Whether you want the full Nix surface area or just reproducible dev environments probably depends on how much of your infrastructure is already in that world.

For developers who want none of that complexity, Oaten doesn't linger: the rest of the video is agnostic about whether you're using devenv or just a vanilla rustup install.

Nightly Rust: Still a Conversation

The recommendation to run Rust nightly, not stable, is the call most likely to raise eyebrows in some circles—and Oaten leans into the history of that skepticism. His response is essentially: the nightlies are, in practice, very stable, and the upside is real.

He offers a concrete example: the new trait solver that landed in nightly can make certain crates—he cites Apache DataFusion—compile more than eight times faster. That's not a rounding error. Compile time is one of Rust's most persistent friction points, and improvements to it land in nightly long before they graduate to stable. For projects where the developer controls the toolchain, the calculus may genuinely favor nightly.

That said, the recommendation isn't universal on its face. There are production contexts—embedded systems, safety-critical applications, regulated environments—where "nightly has been stable for me" is not the kind of assurance that passes muster. Oaten's advice is aimed at the developer who can absorb the occasional rollback, not the team shipping firmware for medical devices.

Cargo's Hidden Depth

One section of the video that deserves attention from newer Rust developers is the Cargo segment—not because the commands are obscure, but because many developers don't realize how much is already there before they install anything.

cargo search, cargo add with feature flags, cargo info—these are built-in, and they keep you in the terminal. cargo-seek wraps them in a TUI for people who want that experience, but the underlying capabilities are native. The point Oaten makes, implicitly, is that the Rust ecosystem invested heavily in tooling ergonomics from the start, and most of it lives in Cargo.

Clippy is the starkest example. Out of the box it's a linter. With the pedantic and nursery lint groups enabled, it becomes something closer to a code reviewer that never gets tired and never takes a long lunch. Oaten's config also adds lints that prevent panicking code outside of test contexts—enforcing at the lint level what Rust's type system alone can't fully guarantee.

Bacon completes this picture: it runs Clippy continuously in a terminal pane as you edit, so you're reading compiler output in real time rather than after the fact. The combination of Bacon + configured Clippy + Rust Analyzer in your editor is, essentially, a feedback loop that most languages require paid tooling to approximate.

The "Personal Standard Library"

The framing Oaten uses for his crate choices is worth noting: he divides them into a "standard library" of crates he uses in every project and a set of "go-to" crates he reaches for in nearly every project. That hierarchy isn't arbitrary—it reflects how mature and settled certain parts of the Rust crate ecosystem have become.

serde for serialization is the clearest example. As Oaten puts it: "If you're not using it directly, your dependencies certainly are." It's not really a choice anymore; it's infrastructure. Same with clap for argument parsing—Rust's built-in argument handling works, but clap's derive macro lets you define your CLI as a struct and get parsing and documentation for free.

For error handling, the community has largely converged on anyhow (or its forks, like eyre and color-eyre) to avoid the boilerplate of specifying every error type a function might return. Rayon gets a brief but notable mention: Oaten recommends trying it before reaching for async frameworks when you need parallelism, on the grounds that if your logic is already built around iterators, switching .iter() to .par_iter() may be all you need.

The more opinionated choices cluster around web: Leptos for frontend, SQLx for compile-time-verified database queries, and Utopia (yes, spelled differently than you'd expect—a pattern in the Rust crate ecosystem that Oaten ribs gently) for generating self-documenting REST APIs. These reflect a specific stack, not universal consensus. The Rust web ecosystem is still somewhat fragmented between Axum, Actix, Rocket, and others, and Oaten's choices here represent one coherent path through that fragmentation, not the only one.

What Kind of Argument Is This?

There's a genre question worth asking about videos like this one. A toolkit video is, structurally, an argument: these choices are better than alternatives. But "better" is always better for something, and Oaten is reasonably transparent about his context. He's building applications—CLIs, web services, frontends—not embedded systems, not libraries for others to consume, not anything where API stability constraints or dependency footprint are overriding concerns.

That context shapes the nightly recommendation, the async skepticism, the Leptos choice. A library author probably has different answers to most of these questions. A developer targeting embedded targets with no_std has a different list entirely.

What makes the video useful isn't that it's universally applicable. It's that it represents a coherent set of choices made by someone who has thought carefully about tradeoffs over several years of Rust production use. "I have been using nightly since 2020," Oaten notes—that's five years of lived experience with the stability question, not a first-week opinion.

The honest reading of any toolkit video is: here's what worked for this person, in this context, with these priorities. The interesting question for any reader is how much of that context overlaps with their own—and which of these crates hold up if it doesn't.