[colin_mccabe]

I think if you are "ripping code in/out of your app everytime you need to do something" for debugging you need to create a logging system with multiple log levels. In log4j you can turn on TRACE logging for a particular subsystem to find out more about what is going on in that system. It would help a lot if the standard Go logging package would support multiple log levels.

[coldtea]

>I think if you are "ripping code in/out of your app everytime you need to do something" for debugging you need to create a logging system with multiple log levels.

That's not a solution for the whole problem of making easy added/rippable changes to check specific behavior.

It leaves the code riddle with log calls and supporting code.

[colin_mccabe]

Adding log messages to code is a good thing. Every complex system needs a way to get visibility into it, and logs are a great way to do that.

I currently work on Hadoop, and pretty much every project in the Hadoop ecosystem has a huge number of log statements. Most of them are turned off at any given time for performance reasons, but when it's really necessary, we can turn them on.

I can see how having a source-code patching system would avoid the overhead of having an "if" statement to check if the log message was enabled. But what are you going to do when the library changes and your patch gets out of date? Having debuggability built-in to the library, rather than available as a 3rd-party add-on, is a feature, not a bug. Hadoop also supports changing the log level at runtime, and it seems like this source code patching system does not. So while this is a very clever system and may have some specific use-cases where it's useful, I think log levels are a better way to go in most cases.