Structured, contextual, extensible, composable logging for Rust
1.7k
Stars
100
Forks
56
Open issues
30
Contributors
AI Analysis
slog is a structured logging ecosystem for Rust offering composable, contextual, and hierarchical logging capabilities. It serves teams building systems that require sophisticated log context tracking and extensibility beyond standard logging. While mature and battle-tested, the README explicitly recommends evaluating the `tracing` crate as an alternative, particularly for async-heavy workloads, positioning slog as best-suited for projects prioritizing API stability, structured log compositio...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Mature Rust structured logging framework facing ecosystem consolidation toward tracing
slog is a battle-tested, component-based structured logging ecosystem for Rust created in 2016. It excels at composable, contextual logging with strong performance and a rich plugin architecture (slog-term, slog-async, slog-json, etc.). However, the README itself explicitly recommends evaluating tracing as the community's preferred solution for most new projects, particularly those requiring async/await support. slog remains actively maintained and stable, but adoption appears concentrated in legacy systems and projects where its specific maturity or features justify the steeper learning curve.
slog emerged in 2016 as an ambitious structured logging alternative to Rust's standard `log` crate. It pioneered composable, contextual logging patterns in Rust and accumulated substantial production usage. The ecosystem accumulated 1,710 GitHub stars and a robust plugin community. However, the rise of tokio-rs/tracing (created later, now 5.6k+ stars) with native async support and larger maintainer backing has shifted the Rust ecosystem's default choice.
slog gained steady adoption through 2016–2020 as the primary structured logging option for Rust. Growth plateaued around 2020–2022 and appears flat since; only 1 star gained in the last 7 days (as of 2026-07-04). The README's candid recommendation to 'consider using tracing instead' signals conscious acceptance of ecosystem consolidation rather than competitive decline. Adoption likely stabilized among projects already using slog and niche use cases valuing its specific design.
README states slog is 'used in many important projects' and references 'crates using slog' on crates.io. However, specific project names, company adoption, or quantified deployment scale are not provided. Reverse dependencies on crates.io would indicate ecosystem integration, but not enumerated here. Adoption not verified at specific scale, though ecosystem integration appears real.
slog appears to use a modular, plugin-based architecture based on the README describing core + optional feature crates (slog-term, slog-async, slog-json, slog-syslog). The core library likely provides traits and composition primitives; functionality is implemented in satellite crates. README emphasizes composability and extensibility. Likely supports context/scope propagation and flexible output formatting.
not documented in README. GitHub Actions workflow shown ('test.yml') indicates CI is active, but test suite size/coverage metrics are not exposed.
Last push: 2026-06-01, approximately 33 days ago from evaluation date (2026-07-04). CI passing. Gitter channel listed as support channel. README acknowledges slower activity and uncertainty around future maintenance ('ownership potentially shared between multiple developers'). Maintenance appears active but cautious; not stagnant, but also not accelerating. The MSRV badge (Rust 1.61+) suggests deliberate compatibility management.
ADOPT IF: you are maintaining a legacy Rust codebase already on slog, need its specific features (e.g., synchronous guaranteed logging, rich composable sinks), prioritize API stability, and do not require first-class async/tracing instrumentation support. AVOID IF: starting a new Rust project with async/tokio, need observability tooling, or want the community's primary solution—use tracing instead. MONITOR IF: you rely on slog and want to track whether maintenance remains sufficient post-2026 as the Rust ecosystem consolidates; the README signals openness to community ownership, which may improve or dilute maintenance quality.
Independent dimensions
Mainstream potential
3/10
Technical importance
7/10
Adoption evidence
5/10
- Ecosystem consolidation: tracing is becoming the Rust standard; slog risks becoming a minority choice, reducing pressure to fix edge cases or maintain compatibility with emerging Rust features.
- Maintenance uncertainty: README explicitly notes 'ownership potentially shared between multiple developers,' signaling governance clarity issues that could lead to slow response to critical bugs.
- Async friction: slog-async exists but is an add-on; tracing's async-first design means async codebases may experience friction with slog's architecture.
- Documentation debt: README acknowledges 'documentation sometimes could use an improvement,' which may persist as community focus shifts to tracing.
- Feature parity risk: if tracing gains features slog lacks (e.g., native span propagation, distributed tracing), migration cost for slog users may increase over time.
slog will likely remain in stable maintenance mode, serving entrenched projects and niche use cases, but will not gain mainstream market share in Rust. Over 5+ years, it may transition to community-maintained status or become a specialized tool for synchronous-only codebases. Adoption curve appears to have flattened permanently.
Explore similar
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://slog.rs/
- Language
- Rust
- License
- Apache-2.0
- Last updated
- 1mo ago
- Created
- 123mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
CI: Run `cargo-semver-checks`
Lazy and cached log fields
[bunyan] Timestamp should be logged in UTC instead of local time
is it possible to init OwnedKV by a hashmap?
Slog does not honor `#[track_caller]`
Top contributors
Similar repos
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
slog-rs/slog
this
|
1.7k | +1 | Rust | 7/10 | 1mo ago |
 rust-lang/log
|
2.5k | — | Rust | 9/10 | 2w ago |
 sirupsen/logrus
|
25.8k | — | Go | 8/10 | 2w ago |
 go-logr/logr
|
1.4k | — | Go | 9/10 | 6d ago |
 serilog/serilog
|
8k | — | C# | 9/10 | 10h ago |
 tokio-rs/tracing
|
6.8k | — | Rust | 8/10 | 1mo ago |
5.6k+ stars vs. 1.7k; async-first design; larger maintainer base; README explicitly recommends tracing as the Rust community's 'go-to' solution. tracing favors observability; slog favors composability and maturity.
2.5k stars; slog is built atop log's trait facade. log is simpler, slog is more feature-rich. log dominates simpler use cases; slog for structured/contextual requirements.
8k stars in different ecosystem. Both offer structured logging and composable sinks. serilog is C#'s de facto standard; slog is Rust's legacy standard being displaced by tracing.
25.7k stars; Go ecosystem standard. Similar era and philosophy to slog (structured, composable). logrus has captured Go mindshare; slog has not in Rust (tracing has).
1.4k stars; structured logging abstraction for Go. Comparable scale to slog; similar positioning as a composable logging layer in a fragmented ecosystem.
