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.
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.
> 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.
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.
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.
Log messages belong on stderr, not stdout. (Despite the name, it is for "diagnostic output" (—man stdio), and using it prevents logs from co-mingling the primary output of the program, if there is one, and even if there isn't, causes all logs to be in an sensible, expected place.)
You're going to want timestamps real quick. If there's one part of the log message that I use, and use a lot, it's the timestamp. When tells you valuable things like "correlates with production outage" or "this operation took way too long".
The tri-value parameter for whether to emit or not emit a newline is, to me, weird. Having three possible inputs where there are only two possible outcomes just seems confusing. Are you just trying to line it up s.t. someone could pass default() and have the "normal" thing happen? (Which wouldn't, if it was a plain bool as you have it now, unless you flipped the boolean.)
This logging library seems to be aimed to be used in CLI application. Decision like adding colors and using emoji makes me believe that.
For servers, structured logging is a must. Each line should have a timestamp like you said. The API should include a context object that can hold information to be logged on each line (like a user ID, request ID, ...).
> Thinking in a CLI, do you think the timestamp is important? I also had this doubt, but it only bothers me.
I suppose it depends, and that point was definitely more subjective. My background is as a backend SWE, so most of my work is server-side. When we/I use CLIs, they're often interacting via the network with other services; while sometimes you're watching it, sometimes you're not, and those timestamps provide useful feedback. If you're building a quick and dirty tool, perhaps not.
I do think the comments in that thread — that you should implement as a log crate Log — are correct. Sooner or later Rust will hopefully have a standard logging mechanism, and the log crate looks like it will be it. But your current implementation should, I think, pretty much naturally fit within that. (I think line endings would be the only thing that doesn't; since log will, eventually, have to support emitting to logs that have no concept of a "line ending", it can't really support that.)
Since when does simple and elegant mean removing vital features like timestamps and proper loglevels while adding pointless emojis into the log? How am I going to search for errors in the log from an SSH console? Search the emoji online, copy & paste it into the shell and hope it works?
Logs aren't meant to be pretty nor elegant. They're meant to help the user fix the problem in a timely manner.
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.