FAQ

Can I try slog without modifying my code (too much)?

Yes. See slog-stdlog crate and slog oldlogging example.

#[macro_use]
extern crate log;
extern crate slog_stdlog;

fn main() {
     slog_stdlog::init().unwrap();
     // Note: this `info!(...)` macro comes from `log` crate, but `slog-stdlog`
     // registered itself above and will delivered it to current `slog-scope`
     // `Logger`. See respective documentation for more information.
     info!("standard logging redirected to slog");
 }

or if you were using env_logger before:

#[macro_use]
extern crate log;
extern crate slog_envlogger;

fn main() {
     let _guard = slog_envlogger::init().unwrap();
     // Note: this `info!(...)` macro comes from `log` crate
     info!("standard logging redirected to slog");
 }

Won't info! and similar macros from slog clash with log macros?

If you start a new project, you should just use slog and not log.

If you're just trying out slog in existing project, you can use slog-stdlog and keep using log crate macros. During transition period to slog, you can use alternative names of slog macros. See slog alternative names example

Can I output file, line module and similar meta-information

Yes. Every closure-value is provided with RecordInfo argument which contains that information. Output it under any name you want, any way you want. See slog file-line-module example.

Can I disable some logging levels at compile time

Yes. slog-rs provides the same Cargo.toml-defined feature-s that standard log did, that allow completely disabling given logging levels at compile time. One difference is, by default slog disables lowest logging levels.

Do I have to pass Logger around?

Not necessarily. You can help yourself using slog-scope.

Note however that slog author advises not using slog_scope at all, and definitely not in libraries.

The reason is: manually passing Logger gives maximum flexibility. Using slog_scope ties the logging data structure to the stacktrace, which is not the same a logical structure of your software. Especially libraries should expose full flexibility to their users, and not use implicit logging behaviour.

Usually Logger instances fit pretty neatly into data structures in your code representing resources, so it's not that hard to pass them in constructors, and use info(self.log, ...) everywhere. Feel free to ask around on gitter channel or check other libraries using slog.

It's advised that libraries follow slog-enabled example library.