exit_safely crate brings safer process exits to Rust on stable

The footgun is familiar: `std::process::exit` ends the process immediately, and that can skip exactly the cleanup Rust developers usually rely on. `exit_safely` is a small crate built to make termination less blunt, and its move onto stable gives CLI tools and services a cleaner way to turn domain errors into controlled exits without scattering ad hoc logic everywhere.

Why this crate matters now

Rust’s standard library already tells you not to treat `std::process::exit` like a casual escape hatch. The docs warn that no destructors on the current stack or any other thread’s stack will run, and they recommend a different pattern when you want a clean shutdown: return a type that implements `Termination` from `main`. That advice is good, but in real codebases it still leaves a gap between “this is the right pattern” and “this is easy to apply consistently.”

That is where `exit_safely` lands with real value. The crate gives you a simple, transparent way to derive `Termination` from your own enum while keeping full control over exit codes and what gets written to stderr. In practice, that makes it a practical upgrade for binaries that want explicit failure handling without a pile of handwritten exit branches.

What stable support changes

The June 13, 2026 forum announcement in The Rust Programming Language Forum marks the key shift: `exit_safely` is now also on stable. That matters because a lot of production Rust teams are allergic to nightly-only dependencies, especially for infrastructure code that has to stay boring, predictable, and buildable across environments.

The stable move lowers the adoption barrier in a very concrete way. You can reach for the crate in a production CLI, a service binary, or an internal tool without signing up for compiler-channel friction. The GitHub repository’s 0.2.1 release also shows a build.rs change to support MSRV 1.85.1, which tells the same story: this is not a flashy packaging stunt, it is compatibility work aimed at real deployment constraints.

What safer termination changes in real code

The nice thing about `exit_safely` is that it does not try to invent a whole new shutdown model. It stays close to the standard library’s own idea of what good process termination looks like, then makes it easier to express. You define your own enum, derive `Termination`, and get an intentional mapping between your application states and the process-level behavior that follows.

That is especially useful in command-line tools where you care about two things at once: the exit code and the message the user sees on stderr. With raw `exit`, those concerns often get wired up manually in a handful of places, which makes the code harder to audit and easier to drift. With `exit_safely`, the handling is centralized and explicit, which is exactly what you want when your binary’s failure modes need to be obvious.

For daemons and long-running services, the benefit is even more practical. A blunt exit can cut through shutdown paths before logs are flushed, temp files are removed, or other cleanup logic gets a chance to run. Rust’s warning about skipped destructors is the real issue here, and `exit_safely` nudges you toward a model where the termination path is part of the program design instead of an afterthought.

Where `exit_safely` fits better than hand-rolled exits

There are a few situations where this crate is the cleaner drop-in choice:

• You want to map domain errors into exit codes in one place, not in every command handler.
• You want stderr output to be controlled by the same enum that defines your termination behavior.
• You are writing a CLI and want `main` to return a `Termination` type instead of calling `exit` directly.
• You are maintaining a service binary and want shutdown behavior that stays explicit and easy to review.
• You want stable Rust, not a nightly dependency, but you still want ergonomic termination control.

That last point is the one teams often underestimate. “We can just use `std::process::exit`” sounds simple until the codebase grows and every crate, subcommand, and error path starts inventing its own tiny exit policy. `exit_safely` is appealing because it removes that drift without hiding what the program is doing.

How it compares with adjacent crates

The ecosystem around termination is already pretty clear-eyed about this problem, and the neighboring crates show different ways Rust users have tried to tame it. The older `exitcode` crate offers named exit-code constants based on `sysexits.h`, which is useful if your main need is standardized exit values. The `termination` crate exposes a `Termination` trait similar to `std::process::Termination`, which keeps you close to the language’s native model.

`exit_safely` carves out a slightly different niche. It combines a derive-based approach with explicit control over both exit codes and stderr output, so it is aimed at developers who want a compact, application-friendly layer rather than a general exit-code catalog or a bare trait wrapper. That combination makes it feel less like a utility you bolt on and more like a small, well-shaped answer to a specific Rust pain point.

The longer arc behind the API

This story also makes more sense when you remember where Rust started. RFC 1011, dated March 24, 2015, said there was then no stable way to exit a program in Rust with a nonzero code without panicking. It also pointed to returning an arbitrary code from `main` as an idea, but noted that doing so would have required incompatible language changes.

That history explains why a crate like `exit_safely` matters even now. The language eventually gave Rust a proper `Termination` story, but application authors still need ergonomics on top of it. `exit_safely` does not change the language, yet it smooths one of the roughest edges between idiomatic error handling and the moment a process actually stops.

The everyday lesson is simple: when a Rust binary exits, you want that decision to be deliberate, not accidental. `exit_safely` gives stable Rust a cleaner way to do exactly that, and for the first time it is easy to adopt without betting your production build on nightly.