3 ms·

> the second one is IO-bound impure one Not necessarily, e.g., you can buffer in memory, and write to storage later. > loggers can fail and break your app An

• shadowgovt 5y ago
  I think the point is "logging isn't free" (in fact, that might make for a better title for the blog post). A lot of devs think of logging as free; it's easy, it's almost always something that's either global-scope or standard library, and it's the first obvious solution to inspect internal program state when the program misbehaves. But logs are a subsystem and adding any subsystem to your code increases your risk surface (for both crashes and privacy violations). Took an operating systems class in college where the first thing the prof drilled into us was "Don't debug with printf. You're going to want to. It's the thing you're most accustom to having written application code. But you're writing an operating system now. If you have a memory overrun, is the first thing you want to do really allocating a kilobyte of stack to mangle strings and determine if you need localization support to tell yourself something's wrong with memory? By the time the output gets emitted to console, the memory you want to inspect will be a blasted wasteland." As an example of how logging can break... > you can buffer in memory, and write to storage later You may as well not have logged then if the failure issue is a segfault; your program context will collapse before the buffer is output.