[csomar]

Are you aware that there is some logging best practices/standards in Rust? I don't mean to be a downer but I'd advice against using this library as it is right now. The reason is that you are not using the Rust Log library: https://docs.rs/log/0.4.6/log/

The good news is that you can integrate your work with the Rust Log library. Basically the difference is: instead of using your logging functions, the user will use the logging macros provided by Log. This means that they can log to the terminal using your library, to a disk file, and to a remote service. All at the same time using the same logging macros.

Here is the Rust Log library description:

> Libraries should link only to the log crate, and use the provided macros to log whatever information will be useful to downstream consumers.

[wokwokwok]

Did something change, or is log not still a global singleton that you register, like you would in go, for database drivers?

The macros are nice and all, but I’m pretty sure the author of log went out and said, yeah well, but you’d disable this in production, because it’s slow and all.

Am I wrong?

Did something change?

You certainly didn’t used to be able to have two different log implementations active in different contexts.

[csomar]

> The macros are nice and all, but I’m pretty sure the author of log went out and said, yeah well, but you’d disable this in production, because it’s slow and all.

You can target code to be executed in debugging vs. production in Rust. So you can have two logging: one for production and one for debugging.

Even better, if you propagate errors back to the top of your program, you'll only have one line for logging for production and the informational logs will remain for debugging only.

[jesusprubio]

You're right, being discussed in other places right now. Finally, changing the description to clarify that the goal is to be used in CLIs, not as a logger.

I prefer to keep lower complexity and there are some crates that cover that case better.

Thank you :).

[csomar]

Quite the opposite. Your solution adds complexity. There is a reason why the log interface was invented and developed. Your solution might seem simple but once you start scaling your projects the deficiencies will surface.

Even if you want to keep the log functions, you can add support for the Log interface. As it is, many people who would otherwise use it, will not.