dlg

I've added a section to the README that goes into the subtleties of compiletime elimination and what to watch out for to ensure that calls to dlg.Printf can actually be eliminated: https://github.com/vvvvv/dlg?tab=readme-ov-file#true-zero-co... I'd appreciate any feedback on whether these changes make the behavior more transparent and less misleading.

It's easy to show that you're right and that code isn't dead so it can't be eliminated: package main import ( "fmt" "github.com/vvvvv/dlg" ) func risky() error { _, err := fmt.Printf("unexpected error\n") return err } func main() { dlg.Printf("something failed: %s", risky()) risky() } prints "unexpected error" twice

Hey HN, I tend to use printf-style debugging as my primary troubleshooting method and only resort to gdb as a last resort. While I like its ease of use printf debugging isn't without its annoyances, namely removing the print statements once you're done. I used to use trace-level logging from proper logging libraries but adding trace calls in every corner quickly gets out of control and results in an overwhelming amount of output. To scratch my own itch I created dlg - a minimal debugging library that disappears completely from production builds. Its API exposes just a single function, Printf [1]. dlg is optimized for performance in debug builds and, most importantly, when compiled without the dlg build tag, all calls are eliminated by the Go linker as if dlg was never imported. For debug builds it adds optional stack trace generation conf