[deathanatos]

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.)

[zimbatm]

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, ...).

[jesusprubio]

An open minded in the forum? I can't believe.

Thank you! :)

[jesusprubio]

Please, see this response: https://news.ycombinator.com/item?id=20028428

Thank you for the feedback.

Thinking in a CLI, do you think the timestamp is important? I also had this doubt, but it only bothers me.

[deathanatos]

> 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.)

[zimbatm]

One thing you can do is detect whenever stderr is a tty and enable timestamping if not