Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Dlg – Zero-cost printf-style debugging for Go

github.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#21

Post by badc0ffee »

9rx wrote: post #16
lanstin wrote: post #14

Earlier quoted context omitted.

Yeah I want a log package where the log statements that don't log also don't have their arguments evaluated. Half of my gc pressure is little strings created to call the log package that don't get logged.

So what you want is slog, found in the standard library? The doc.go file found in the package even goes into detail about what you (seem to) describe and how it avoids that problem.

A link to doc.go, for the lazy:

https://cs.opensource.google/go/x/exp/+/645b1fa8:slog/doc.go...

Basically it says to pass in objects, not prepared strings, so the formatted output is only computed if the message is actually logged. That object can be a struct implementing the LogValuer interface to do any required work/produce formatted output.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#22

Post by 0xFEE1DEAD »

9rx wrote: post #20
0xFEE1DEAD wrote: post #17

Earlier quoted context omitted.

I do write tests but I'm not a fan of aiming for 100% coverage because it's incredibly tedious to achieve, and the gains in my experience are marginal. That being said even with 100% coverage your code may still contain bugs. If you've never had to debug code with extensive tests then hats off to you.

When you write a test you see the cute little "debug test" button show up beside it in your editor. If you press it, your logpoints spill the logging information you seek without having to modify the code. I expect that is what the parent is really asking about: What does this meaningfully offer over the "built-in" debug logging?

Well, my vim is missing buttons like these and I wasn't aware such a feature existed.

Maybe I'm just old, maybe it's just a different approach, but I built dlg for myself because it fits my workflow.

> What does this meaningfully offer over the "built-in" debug logging?

For you, it most likely doesn't offer anything meaningful.

For devs who use fmt.Printf a lot, it maybe does.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#23

Post by lanstin »

badc0ffee wrote: post #21
9rx wrote: post #16

Earlier quoted context omitted.

So what you want is slog, found in the standard library? The doc.go file found in the package even goes into detail about what you (seem to) describe and how it avoids that problem.

A link to doc.go, for the lazy: https://cs.opensource.google/go/x/exp/+/645b1fa8:slog/doc.go... Basically it says to pass in objects, not prepared strings, so the formatted output is only computed if the message is actually logged. That object can be a struct implementing the LogValuer interface to do any required work/produce formatted output.

Oh cool, I hadn't run into LogValuer, that's cool. And passing pointers to strings rather than strings, hmmm.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#24

Post by latchkey »

0xFEE1DEAD wrote: post #17
latchkey wrote: post #13

I'm curious why you prefer this over writing tests.

I do write tests but I'm not a fan of aiming for 100% coverage because it's incredibly tedious to achieve, and the gains in my experience are marginal. That being said even with 100% coverage your code may still contain bugs. If you've never had to debug code with extensive tests then hats off to you.

Crazy that I get downvoted for a perfectly valid question, go HN!

I'm not saying that tests are perfect, but if you do find a bug, you write a new test and fix it. You don't add print statements that you expect to keep around any longer than the amount of effort there is to write the test and fix the code.

Maybe this product is for people who don't write tests, but even in this codebase, there is a pretty well done set of tests and zero dogfood usage that I noticed.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#25

Post by latchkey »

0xFEE1DEAD wrote: post #22
9rx wrote: post #20

Earlier quoted context omitted.

When you write a test you see the cute little "debug test" button show up beside it in your editor. If you press it, your logpoints spill the logging information you seek without having to modify the code. I expect that is what the parent is really asking about: What does this meaningfully offer over the "built-in" debug logging?

Well, my vim is missing buttons like these and I wasn't aware such a feature existed. Maybe I'm just old, maybe it's just a different approach, but I built dlg for myself because it fits my workflow. > What does this meaningfully offer over the "built-in" debug logging? For you, it most likely doesn't offer anything meaningful. For devs who use fmt.Printf a lot, it maybe does.

I'm 52 and coding since I was about 10 years old, so I'm not sure age is the right thing to go off.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#26

Post by 9rx »

lanstin wrote: post #23
badc0ffee wrote: post #21

Earlier quoted context omitted.

A link to doc.go, for the lazy: https://cs.opensource.google/go/x/exp/+/645b1fa8:slog/doc.go... Basically it says to pass in objects, not prepared strings, so the formatted output is only computed if the message is actually logged. That object can be a struct implementing the LogValuer interface to do any required work/produce formatted output.

Oh cool, I hadn't run into LogValuer, that's cool. And passing pointers to strings rather than strings, hmmm.

> And passing pointers to strings rather than strings, hmmm.

Are you referring to the "URL" example? That isn't a case of passing pointers to strings, that is passing a URL (fmt.Stringer) where the String method has a pointer receiver.

To demonstrate why the pointer would be needed in that case, consider:

    type URL struct{}
    func (*URL) String() string { return "https://..." }
    func print(v any)           { fmt.Println(v.(fmt.Stringer).String()) }
    func main() {
        print(&URL{}) // ok
        print(URL{})  // panic
    }

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#27

Post by shayief »

smcameron wrote: post #3

> printf debugging isn't without its annoyances, namely removing the print statements once you're done. Use something like stacked git[1], and then it's just one "stg pop" and poof, they're gone. [1] https://stacked-git.github.io/

I usually leave them as uncommitted changes, then git checkout to undo them. And using something like `git add -p` to skip Printfs if I need to commit other changes.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#28

Post by 0xFEE1DEAD »

latchkey wrote: post #24
0xFEE1DEAD wrote: post #17

Earlier quoted context omitted.

I do write tests but I'm not a fan of aiming for 100% coverage because it's incredibly tedious to achieve, and the gains in my experience are marginal. That being said even with 100% coverage your code may still contain bugs. If you've never had to debug code with extensive tests then hats off to you.

Crazy that I get downvoted for a perfectly valid question, go HN! I'm not saying that tests are perfect, but if you do find a bug, you write a new test and fix it. You don't add print statements that you expect to keep around any longer than the amount of effort there is to write the test and fix the code. Maybe this product is for people who don't write tests, but even in this codebase, there is a pretty well done s…

> but if you do find a bug, you write a new test and fix it.

Maybe there's a misunderstanding here but this library is not meant to replace tests. It's for initially finding the bug for which you then write a test case (or not).

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#29

Post by latchkey »

0xFEE1DEAD wrote: post #28
latchkey wrote: post #24

Earlier quoted context omitted.

Crazy that I get downvoted for a perfectly valid question, go HN! I'm not saying that tests are perfect, but if you do find a bug, you write a new test and fix it. You don't add print statements that you expect to keep around any longer than the amount of effort there is to write the test and fix the code. Maybe this product is for people who don't write tests, but even in this codebase, there is a pretty well done s…

> but if you do find a bug, you write a new test and fix it. Maybe there's a misunderstanding here but this library is not meant to replace tests. It's for initially finding the bug for which you then write a test case (or not).

It isn't clear how this library helps one find bugs.

Re: Show HN: Dlg – Zero-cost printf-style debugging for Go

#30

Post by norir »

dspillett wrote: post #18
sigmonsays wrote: post #12

it doesn't appear to truly be zero cost if you log variables that can't be eliminated. The only way (I believe) to implement zero cost is some type of macro system which go does not support.

> it doesn't appear to truly be zero cost if you log variables that can't be eliminated. I'd say it is fair to call it zero cost, if the costs you are seeing are due to the way you are using it. If the values being logged are values you are already computing and storing, constants, or some mix of the two (concatenated via its printf function), by my understanding (caveat: I've never actually used Go myself) all the l…

The problem is calling anything zero cost is inherently wrong. Nothing in life has no cost. I know I am being pedantic but I think a more accurate description is "zero production runtime cost," which is also how I interpret rust's zero cost abstraction. In that case too, I find the terminology grating because there are very obviously costs to using rust and its abstractions.

One obvious cost to code that is removed in production is that there is now a divergence between what your source code says it does and what it actually does. I now need to keep in mind the context the program is running in. There is a cost to that. It might be worth it, but it isn't zero.

Post reply on HN