Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

This is really cool! One suggestion: logging to a file makes it harder for things like Docker to exfiltrate logs. Log to stderr by default, and the caller can redirect to a file on disk if they want to.

View on HN

Why log to stderr instead of just stdout?

Maybe just convention? It's standard practice to use stdout for directly interacting with a user and stderr for log/error type messages. You can redirect stderr to a file to get all of your log messages, but keep stdout available for interacting with the user. Super useful to separate meta-messages out in this manner.

Here's a good blog post with more info on stderr for those interested: https://www.jstorimer.com/blogs/workingwithcode/7766119-when...

Might be because stdout is buffered, so you don't always get output right away, while stderr is unbuffered.

You split the user interaction from the logging. In the case of the webserver maybe this a less of an issue, but if I'm processing text output from an application I don't want a log message inserting itself in the middle of the output.

Cool and thanks for the feedback - yup, I actually played around with deploying it using GCP and had issues due to the logging, so I definitely regret not using stderr/stdout!!

Not be to dogmatic but thus is really good:

> A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout.

Then, switching log provider is done globally, on the environment level (eg. installed on k8s)

https://12factor.net/logs

Cool - thanks a bunch for the info and the link! It looks like a great read with terrific practices :)

Reply on news.ycombinator.com