
Show HN: Leg – Simple, elegant logging for Rust - jesusprubio
https://github.com/jesusprubio/leg
======
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/](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.

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

~~~
jesusprubio
Please, see this response:
[https://news.ycombinator.com/item?id=20028428](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.)

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

~~~
jesusprubio
Please, see this response:
[https://news.ycombinator.com/item?id=20028428](https://news.ycombinator.com/item?id=20028428)

Thank you for the feedback.

------
siscia
Thanks for your work!

Why the log functions takes three arguments? One of which is an option of
bool?

An interesting idea would be an enhancement of the dbg! macro.

~~~
jesusprubio
The third one is to use `print!` instead of `println!` to keep the cursor in
the same line.

Thank you for the feedback!

------
EugeneOZ
Only reason to share this not-so-outstanding library is "it's written in
Rust"?

Rust is my favorite language, but it becomes silly - every day some not-so-
outstanding copy of existing tool in Rust on the first page of HN.

~~~
jesusprubio
About the first page of HN I agree, it's crazy xD. I wrote it as my second
crate to learn about the environment.

But I truly believe in this micro modules way of building things. If it
reduces complexity it's welcome. :)

