flow-storm-debugger VS delve

Tracing debuggers give you the best of both worlds. I've recently started using Flow-storm [0], by @jpmonettas), and it's been quite transformative. You can still easily see the values flowing through your system (better than just "prints"), and it can handle multi-threaded / async scenarios quite nicely. You don't need to manually step through code, you can just "see" your data flow, and when you have loops or some other form of iteration, you can see the data for each pass. Coupling this with a good data visualization tool (such as Portal [1]) really feels like magic. I've been doing Clojure for quite a few years now, and was very happy with my plain REPL-driven workflow, but this is way better.

[0] https://github.com/jpmonettas/flow-storm-debugger

[1] https://github.com/djblue/portal

This is another example, a tracing time travel debugger for Clojure https://github.com/jpmonettas/flow-storm-debugger

Supports a bunch of stuff described there and more.

Lisps have some good tooling around debugging, for example clojure's flowstorm or common lisp which has built into the language most of what this article is talking about.

There's some good debugging tooling for Clojure as well. A recent entrant is https://github.com/jpmonettas/flow-storm-debugger and of course there's the estabilished pretty full featured debugging features in CIDER (Emacs), Calva (VS Code) and Cursive (IntelliJ). And for barebones tracing from REPL there's goo old clojure.tools.trace.

For Emacs there is something already if you use the Emacs integration described here https://github.com/jpmonettas/flow-storm-debugger/tree/flow-docs/editors.

At a recent job, we had slightly different containers for local dev; our backend containers (for a Go app) had Air [1] installed for live reloading, plus Delve [2] running inside the container for VS Code's debugger to connect to. We also had a frontend container for local dev, which didn't get deployed as a container, just as static files.

[1] https://github.com/cosmtrek/air

[2] https://github.com/go-delve/delve/

https://github.com/go-delve/delve/releases/tag/v1.21.2 Thanks Derek and the rest of the team for helping us to debug in a normal way!

My employer has a commercial solution for this but Delve does supports `rr` traces natively for this purpose, which gives a complete open-source solution (https://github.com/go-delve/delve/blob/master/Documentation/usage/dlv_replay.md).

delve and related IDE integrations

For time travel debugging in Go:

The Delve debugger for Go supports debugging rr traces: https://github.com/go-delve/delve/blob/master/Documentation/...

Undo (who I work for) maintain a fork that debugs our LiveRecorder recordings: https://docs.undo.io/GoDelve.html

Either rr (https://rr-project.org/) or our UDB debugger (https://undo.io/solutions/products/udb/) can do some time travel debugging of Go programs via GDB's built-in support for Go. I believe its weakness is in support for goroutines, since they don't map well onto its idea of how programs run.

So in my case I use https://github.com/leoluz/nvim-dap-go (which itself calls out to the CLI tool https://github.com/go-delve/delve).

Clone https://github.com/go-delve/delve.git