5 ms·

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime wit

Counterpoint: nope. Logging is great for long term issue resolution. There's tracepoints/logpoints which let you refine the debugging experience in runtime without accidentally committing prints to the repo. There are specific types of projects that are very hard to debug (I'm working on one right now), that's a valid exception but it also indicates something that should be fixed in our stack. Print debugging is a hack, do we use it? Sure. Is it OK to hack? Maybe. Should a hack be normalized? Nope. Print debugging is a crutch that covers up bad logging or problematic debugging infrastructure. If you reach for it too much it probably means you have a problem.

bogota 2y ago
What is the difference between print debugging and logging? With most deployments setups now days you can pipe prints to some logging solution anyways.
- invalidname 2y ago
  Print is ephemeral by design. Logging lets you refine the level of printing and is designed to make sense in the long term. There are many technical differences (structured logging, MDC etc.) that I won't get into but they are important. To me it's mostly about the way you write the logs vs. the way you write a print. A log tries to solve the generic problem so you can deal with it in production if the need arises by dynamically enabling logs. It solves the core issue of a potential problem. A print is a local bandaid. E.g. when print debugging one would write stuff like "f*ck 1 this was reached"... In logs you would write something sensible like "Subsystem X initialized with the following arguments %s". That's a very different concept.
  - ricktdotorg 2y ago
    totally agree re: structured logging. my intro to that was w/GCP Logging and it changed my mind on when and what to log. proper structured logging and keying metrics/alerts from those metrics is extremely satisfying and legitimately useful.
nofunsir 2y ago
Agree. Safety critical kernels do not even have printf.
tliltocatl 2y ago
If your code is connected to some external factory, it's impossible to pause on a breakpoint without breaking everything. And no, "just mock it" doesn't work if you have no idea on how the factory actually behaves. Printf is good because it doesn't messes up timing.
- invalidname 2y ago
  I suggest re-reading my comment and learning about tracepoints/logpoints. Your comment highlights my exact problem with print debugging... You just aren't aware of the tools available to you and you reach to the rusty old broken hammer.
- mark_undoio 2y ago
  Time travel debugging (https://en.wikipedia.org/wiki/Time_travel_debugging https://en.wikipedia.org/wiki/Time_travel_debugging) can be good for this situation too because it separates capturing a bug ("recording") and understanding it (the debugging phase, which happens while "replaying"). You don't need to pause anything whilst capturing the bug. Now, if your code is literally connected to running critical systems in an actual factory then you've probably got additional realtime and safety-critical considerations that might push you towards debugging. But (for more conventional use cases) time travel debuggers can handle multiple communicating systems without causing timeouts, capture bugs in software that interacts directly with hardware devices, etc. And you don't have to keep rebuilding / rerunning once you've reproduced the bug.

bogota 2y ago

What is the difference between print debugging and logging? With most deployments setups now days you can pipe prints to some logging solution anyways.

invalidname 2y ago
Print is ephemeral by design. Logging lets you refine the level of printing and is designed to make sense in the long term. There are many technical differences (structured logging, MDC etc.) that I won't get into but they are important. To me it's mostly about the way you write the logs vs. the way you write a print. A log tries to solve the generic problem so you can deal with it in production if the need arises by dynamically enabling logs. It solves the core issue of a potential problem. A print is a local bandaid. E.g. when print debugging one would write stuff like "f*ck 1 this was reached"... In logs you would write something sensible like "Subsystem X initialized with the following arguments %s". That's a very different concept.
- ricktdotorg 2y ago
  totally agree re: structured logging. my intro to that was w/GCP Logging and it changed my mind on when and what to log. proper structured logging and keying metrics/alerts from those metrics is extremely satisfying and legitimately useful.

nofunsir 2y ago

Agree. Safety critical kernels do not even have printf.

tliltocatl 2y ago

If your code is connected to some external factory, it's impossible to pause on a breakpoint without breaking everything. And no, "just mock it" doesn't work if you have no idea on how the factory actually behaves. Printf is good because it doesn't messes up timing.

invalidname 2y ago
I suggest re-reading my comment and learning about tracepoints/logpoints. Your comment highlights my exact problem with print debugging... You just aren't aware of the tools available to you and you reach to the rusty old broken hammer.
mark_undoio 2y ago
Time travel debugging (https://en.wikipedia.org/wiki/Time_travel_debugging https://en.wikipedia.org/wiki/Time_travel_debugging) can be good for this situation too because it separates capturing a bug ("recording") and understanding it (the debugging phase, which happens while "replaying"). You don't need to pause anything whilst capturing the bug. Now, if your code is literally connected to running critical systems in an actual factory then you've probably got additional realtime and safety-critical considerations that might push you towards debugging. But (for more conventional use cases) time travel debuggers can handle multiple communicating systems without causing timeouts, capture bugs in software that interacts directly with hardware devices, etc. And you don't have to keep rebuilding / rerunning once you've reproduced the bug.