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

31–40 of 42 posts

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

#31

Post by danudey »

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…

I think you're getting downvoted because it's not a valid question - debug logging and unit testing are two separate things, and the OP didn't say anywhere that he prefers this to unit tests. Your question presupposes a dichotomy that doesn't exist.

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

#32

Post by danudey »

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

Earlier quoted context omitted.

> 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.

If you're not sure how logging debug information can help you find bugs then I'm not sure what to say. Especially if you've been programming for four decades, I would think it would be obvious how logging information can help you find logic or data errors in your code/inputs/outputs.

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

#33

Post by latchkey »

danudey wrote: post #32
latchkey wrote: post #29

Earlier quoted context omitted.

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

If you're not sure how logging debug information can help you find bugs then I'm not sure what to say. Especially if you've been programming for four decades, I would think it would be obvious how logging information can help you find logic or data errors in your code/inputs/outputs.

I know how to write failing tests, and use a debugger.

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

#34

Post by latchkey »

danudey wrote: post #31
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…

I think you're getting downvoted because it's not a valid question - debug logging and unit testing are two separate things, and the OP didn't say anywhere that he prefers this to unit tests. Your question presupposes a dichotomy that doesn't exist.

My statement certainly had some implied subtext that I can expand upon now...

If you write tests, you don't need a specialized library for debug logging.

Run the test, and set a breakpoint in your debugger.

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

#35

Post by danudey »

latchkey wrote: post #34
danudey wrote: post #31

Earlier quoted context omitted.

I think you're getting downvoted because it's not a valid question - debug logging and unit testing are two separate things, and the OP didn't say anywhere that he prefers this to unit tests. Your question presupposes a dichotomy that doesn't exist.

My statement certainly had some implied subtext that I can expand upon now... If you write tests, you don't need a specialized library for debug logging. Run the test, and set a breakpoint in your debugger.

This is only mildly offtopic, but I wonder if the following is true:

Software developers who...

1. Experienced actual instruction on software development;

2. Learned to write software in C/C++/FORTRAN/Pascal/whatever; or

3. Spent a lot of time in more niche situations like system programming, embedded programming, enterprise systems, etc.

...are familiar with using debuggers as part of their workflow to inspect internal state and diagnose. In contrast, developers who...

1. Were entirely self-taught;

2. Grew up on interpreted languages (JS, Python, PHP, Perl, etc); and

3. Generally tend to write smaller, self-contained projects

...tend to just add debug logging and re-run the program.

I definitely have used debuggers in the past, but as someone who almost exclusively has written in interpreted languages (or languages where the write-compile-run loop is fast, e.g. Golang), my habit is to add debug logging to more places to validate internal state as the program runs, rather than attaching a debugger and inspecting specific things manually.

Either way, I think it's two separate approaches and I think in different circumstances there are definitely benefits to one or the other. In most of my Python scripts it's faster to add a `print(f"variable is {variable}")` than it would be to attach a debugger; also for a small script that's only going to run a few times, or run very occasionally, writing unit tests is often overkill because often the entire script is effectively a unit.

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

#36

Post by latchkey »

danudey wrote: post #35
latchkey wrote: post #34

Earlier quoted context omitted.

My statement certainly had some implied subtext that I can expand upon now... If you write tests, you don't need a specialized library for debug logging. Run the test, and set a breakpoint in your debugger.

This is only mildly offtopic, but I wonder if the following is true: Software developers who... 1. Experienced actual instruction on software development; 2. Learned to write software in C/C++/FORTRAN/Pascal/whatever; or 3. Spent a lot of time in more niche situations like system programming, embedded programming, enterprise systems, etc. ...are familiar with using debuggers as part of their workflow to inspect inter…

I don’t know if you’re trying to make assumptions about me or you, but I am those 3 things.

It is definitely different approaches and both can achieve the same goals, but having started with your approach and then learned IDE’s, debugging and writing tests, I can from my own experience say that tests and debuggers are the way to go when it comes to building long term stable applications, especially in shared environments.

As for speed to attach a debugger? Lol, it is one button click in a proper IDE and the speed and utility of figuring out the solution is faster. What I am hearing from you is that you’re unwilling to put the time into learning/using the tools. Or maybe you’re just stuck in your own headspace, many developers get that way, it is why we have editor wars and whatnot.

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

#37

Post by 0points »

> Any feedback is much appreciated.

There is way too much going on in this code whose feature essentially boils down to

    func Printf(f string, v ...any) {
        if CONDITION {
         fmt.Printf(f, v...)
        }
    }
Writing a stack trace is fully unrelated to Printf(), and should be separated.

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

#38

Post by [deleted] »

llimllib wrote: post #9
mdaniel wrote: post #8

How does the dead code elimination work when using args to Printf? If static strings are fed into an empty function, I can imagine it does nothing. However, this I have less of a firm grip upon dlg.Printf("the thing.Something is %+v", thing.Something()) since surely golang will still call Something, and still call Printf And don't misunderstand me: it's a grave pet peeve of mine to do action inside the args to Printf…

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

[deleted]

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

#39

Post by 0points »

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.

> I'm not a fan of aiming for 100% coverage

"100% coverage" is just a measure of line coverage and is highly useless to reason about.

For testing to become meaningful, you should have test data covering way more than that for the relevant parts.

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

#40

Post by danudey »

latchkey wrote: post #36
danudey wrote: post #35

Earlier quoted context omitted.

This is only mildly offtopic, but I wonder if the following is true: Software developers who... 1. Experienced actual instruction on software development; 2. Learned to write software in C/C++/FORTRAN/Pascal/whatever; or 3. Spent a lot of time in more niche situations like system programming, embedded programming, enterprise systems, etc. ...are familiar with using debuggers as part of their workflow to inspect inter…

I don’t know if you’re trying to make assumptions about me or you, but I am those 3 things. It is definitely different approaches and both can achieve the same goals, but having started with your approach and then learned IDE’s, debugging and writing tests, I can from my own experience say that tests and debuggers are the way to go when it comes to building long term stable applications, especially in shared environm…

> I can from my own experience say that tests and debuggers are the way to go when it comes to building long term stable applications, especially in shared environments.

Ah, so there's the distinction for me - I don't build long-term stable applications in shared environments, I build small utilities or one-offs in private or occasionally shared environments.

> As for speed to attach a debugger? Lol, it is one button click in a proper IDE and the speed and utility of figuring out the solution is faster.

For me, I haven't used "a proper IDE" for most of my projects - again, because the nature of my projects has never required it, nor are any of my projects long-term enough or complex enough to bother configuring anything. I just open a default configuration of vim, type what I need to, and then I'm done.

> What I am hearing from you is that you’re unwilling to put the time into learning/using the tools.

Maybe more like "I don't see any benefit setting up an entire IDE and learning how to use the debugger to diagnose a 200-line Python file that runs in 0.8 seconds.

> Or maybe you’re just stuck in your own headspace, many developers get that way, it is why we have editor wars and whatnot.

I would turn this around - because I don't use an IDE that I've spent time configuring and customizing, and learning how to use the tools it provides to be more efficient, I'm less invested in which editor I'm using. I certainly get used to certain editors so I don't just randomly select a text editor each time I need to write something, but I would argue that the time and effort spent integrating yourself with a specific IDE and configuration makes someone more likely to "editor wars" than not doing so.

Fundamentally, I understand the core benefits of using a debugger in the abstract; I see why and how it's useful, especially if you're able to do things like attach a debugger to a running process and inspect an error case as it's happening rather than having to reproduce it locally (or e.g. in a unit test). That said, I cannot see any way in which my workflow would be improved by that level of integration with an IDE when my current approach - useful debug logging - only has to be added to a program once, is useful for debugging this problem and any other down the road, and works whether I'm editing code locally in VS Code or SSH'ed into some remote machine running a cut-down version of Vim.

Post reply on HN