slog: a small logging core with an ecosystem of feature crates around it

The README tells you to use something else

The first section of the README is a recommendation to look elsewhere, and it is worth quoting because it is unusual. It says you might consider using `tracing` instead, that it has been a while since slog was created and it served the Rust community well all this time, that it remains a stable, featureful and battle-tested library used in many important projects, and that in the last few years another ecosystem for Rust was created with similar features and very good support for debugging `async` code, with an already larger development team and community. The conclusion is that `tracing` seems to already be a go-to logging or tracing solution for Rust. Then the README lists the reasons you might stay anyway, and they are specific rather than sentimental. The `async` support does not benefit you, you consider mature, stable code and API a plus, it has some features that `tracing` is missing, and its performance is very good, with the author immediately adding that he has NOT done any comparison. That caveat is a good sign about the rest of the documentation.

A core library and a dozen satellites

The README is explicit that `slog` is just a core, and that the actual functionality is inside many feature crates. The ones it names are `slog-term` for terminal output, `slog-async` for asynchronous logging, `slog-json` for JSON output, `slog-syslog` for syslog, and `sloggers` for convenience methods, which it marks as a third-party library rather than a first-party one. The architecture is the interesting part, because it is the standard Rust answer to a library that wants to be small. The core defines the logger traits, the key-value machinery and the composition model, and everything that touches a format, a transport or a platform lives in a separate crate that depends on the core and nothing else. The README says there are many more slog feature crates, that it is easy to write and publish new ones, and that you can look through the crates that depend on slog for examples and ideas. If you are choosing between a full framework and a set of parts, that is the shape of the choice.

Nested values, and the fix that shipped in 2.8.2

The most consequential feature change in the recent releases is nested values, and the manifest documents it in unusual detail. The `nested-values` feature is enabled by default, it pulls in the erased serde and serde core dependencies, and the comment explains why you want it, that it is recommended to improve the detail of log messages, and that without it only flat values such as numbers and strings can be logged. The feature also requires the underlying logger to support it, usually through a matching feature flag on the backend, so it is not entirely within your control. The recent release titles show the churn. Version 2.8.0 enabled the nested values feature by default, 2.8.1 moved back to erased serde 0.3, and 2.8.2 fixed a private field that broke the `#` operator in the macros. That last one is a good illustration of the cost of a macro based API, and it is the kind of change a changelog exists to explain.

The MSRV policy, written out in the manifest

The Cargo.toml carries its own policy in comments, which is unusual and useful. The minimum supported Rust version is 1.61, and the comment spells out the rules, that bumping the MSRV requires increasing the minor version number, from 2.7 to 2.8, that changes must be clearly announced in the CHANGELOG.md file, and that at a minimum the project must support at least the latest stable Rust minus fifteen releases, with the note that they can and often do support versions much older than that. The comment also says this must be kept in sync with the GitHub Actions test workflow, the README and the clippy configuration, which is a small but telling detail, because it means the version floor is checked in more than one place. The package uses the 2018 edition, and the release profile is tuned, with optimisation level 3, link time optimisation enabled, debug info off and debug assertions off.

Building, testing and the awkward target names

The Makefile is a thin wrapper over cargo, and it shows the shape of the development work. The `run`, `test`, `build` and `clean` targets call the matching cargo subcommand, `check` is separate, and `clippy` is a build with the clippy feature enabled. There is a `bench` target and a `benches.txt` file at the root, and a `longtest` target that loops the test suite indefinitely until you interrupt it, which is the kind of target a library with concurrency in it needs. The examples are built by name, with the Makefile discovering them from the examples directory, and two of them are wired specially. `named` and `struct-log-self` build the examples by name, while `singlethread` builds with the `nothreads` feature, so the single threaded path gets exercised as its own configuration. Documentation is generated with `cargo doc` and published to a gh-pages branch through a `ghp-import` step, with a `docview` target that opens the result locally.

Governance, verification and the wider ecosystem

The community section explains that Dawid Ciężarkiewicz is the original author and current maintainer and therefore the self-appointed benevolent dictator over the project, that he follows and expects everyone to follow his code of conduct, and that particular repositories under the slog ecosystem might be created, controlled and maintained by other entities with various levels of autonomy. The verification recommendation is the part with practical value, that since the ownership of the crate is potentially shared between multiple developers, it is recommended to always use cargo-crev to verify the trustworthiness of each of your dependencies, including this one. Help is offered through the gitter channel, the wiki holds a getting started page, an introduction to structured logging with slog and an FAQ, and the full API documentation with examples is hosted on docs.rs, which the README says is where most of the interesting documentation lives.

Editorial conclusion

Adopt slog if you want structured logging with a stable API, you are not leaning on async tracing, and you are willing to assemble the output format and backends you want from the feature crates rather than take one integrated stack. Do not start a new project on it without reading the README's advice, because the maintainers themselves point at `tracing` as the go-to option with a larger team and better async debugging support. Before you pin a version, check the minimum supported Rust version, which is 1.61 with a stated policy of supporting at least the latest stable Rust minus fifteen releases, and note the tri-licence, which is MPL-2.0 or MIT or Apache-2.0, so it fits into almost any project. The newest release is 2.8.2 from 2025-10-11, and the last push was on 2026-06-01.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. slog-rs/slog on GitHub