"debugging in the sunset" generated by Midjourney
This has quite a few downsides. In particular, it's much more difficult to debug code outside of the code you wrote. If I want to inspect functions from other libraries -- including standard libraries -- I'd have to find where the library is located in my filesystem and add log statements there. Not great. Another major downside is the debugging workflow. Everytime I want to log a variable, I have to add the log statement and then rebuild and run the code again. It can be pretty slow sometimes.
This habit persisted until John Carmack debug-shamed me on Lex Friedman's podcast.
If John Carmack is telling me I'm missing something, I should probably listen. So I put my bad habits back in my toolbelt and decided to try to debug using an actual debugging tool.
Recently I've been doing quite a bit of work in golang. The entire pico ecosystem of services are built using golang.
One thing that I did not want to do is switch away from my terminal-based
workflow. All the debuggers I've seen colleagues use are embedded inside their
IDE. I use
neovim so I first started by going to
neovimcraft1 and searching for golang debuggers.
It seems that delve is the most popular debugger for golang.
After looking at the neovim integrations, I decided that they were not going to work for me. I like to keep my plugin list minimal because I tend to forget what I have installed.
Instead I decided to use the CLI tool
dlv that comes with
delve.2 It's a
little more manual, but when I'm trying to learn something new I tend to go with
the easiest implementation in order to learn how it works. Adding an integration
in between me and
delve was too much overhead for me to think about
After using this tool for a couple of weeks, I learned how to:
- run it with web and ssh servers
- step through a program
- add/remove breakpoints
- rebuild the code when I make a change
- print/set variables
- call functions
I have definitely noticed an improvement in how quickly I can debug an issue. Like John Carmack mentioned, when building a new feature, I often start by running the server inside the debugger.
Another clear benefit is that I'm finding myself debugging library code a lot more. I'm reading the code as I'm debugging, finding issues, and then submitting tickets or patches to those projects. Libraries feel less like black boxes and more porous. They feel within my grasp.
So thank you John Carmack for helping me understand what I was missing.