Here it is.
Modern Command-Line Rust: A Practical Guide to Tools and Automation
You've written the tool. It works on your machine. Then it goes into CI, or someone else's environment, or a pipeline you didn't design, and something breaks in a way you can't immediately explain. The binary assumes a TTY that isn't there. Color codes leak into downstream parsers. A panic dumps an unhelpful stack trace into a log that a JSON processor was expecting to be clean. The tool wasn't wrong, exactly. It just wasn't ready for the world it entered.
This is the problem that most Rust CLI tutorials don't address-because tutorials test in controlled conditions, and real tools don't live there.
Modern Command-Line Rust was written from the other side of those failures. Not from a position of theoretical best practices, but from years of building tools that broke in production, maintaining scripts that grew beyond what scripts were meant to hold, and learning-sometimes slowly-what separates a CLI that people actually use from one that gets quietly abandoned after the second edge case.
The tools that survive aren't always the fastest. They aren't always the most featureful. They're the ones that behave correctly when the environment isn't what the author expected. They compose cleanly with other tools without corrupting data. They fail clearly, with messages that tell you what happened and why, instead of swallowing errors or panicking into silence. They start fast, stay predictable, and don't surprise users who aren't looking for surprises.
Getting there requires making decisions that most documentation glosses over-when to check for a TTY and change behavior accordingly, how to structure a project so it stays maintainable past the first thousand lines, how to handle dependencies without accumulating invisible risk, how to write error types that carry meaning instead of just propagating noise, how to make a tool portable across environments you don't control. These decisions are rarely the exciting ones. They're the ones that determine whether a tool earns a permanent place in someone's workflow or gets replaced the first time it misbehaves.
This book works through all of it. Project structure that doesn't collapse as the codebase grows. Cargo beyond cargo build-workspaces, profiles, dependency auditing, reproducible builds. Argument parsing that handles the edge cases clap's documentation mentions but doesn't fully explain. Output that knows whether it's talking to a human or a pipeline. Error handling that communicates rather than just propagates. Performance that's real and felt, not just visible in benchmarks. Distribution that actually works on the target machines.
Along the way it draws on tools like ripgrep, fd, and bat-not as things to admire from a distance, but as case studies in specific decisions: why ripgrep's defaults encode years of experience into a single invocation, how fd made opinionated choices that turned out to be right for most people most of the time, how bat stays composable while adding capabilities that lesser tools would use to break composability.
If you've been building Rust CLI tools and something keeps going wrong in ways you can't fully articulate-if your tools work until they're in someone else's hands, or compose until they're in a real pipeline, or perform well until they're on real data-this is the book that names the problem and works through the fix. Not in theory. In the specific, unglamorous detail that real tools require.
