EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.
A couple of details have changed since that post. The only one that you might care about is that I now have two tmux panes with gdb-dashboard. This is meant to use space better. One pane has all of the variables and nothing else. The other has everything else.
If you care about that, I'll tell you how to do it.
[1]: https://gavinhoward.com/2020/12/my-development-environment-a...
To that end I would say Intellij products have the best debugging experience I've found on Linux. VS Code after that.
I did have a couple of plugins I cant really live without (ZoomWinTab and A.vim) so Im working on porting them to lua with the help of chatgpt. Really like the experience so far. Def worth checking out astronvim / nvchad
Debugging in proper Visual Studio is by far the most pleasant experience I have ever had. Flame graphs, call graphs, memory and CPU utilisation graphs, straightforward call stacks and variable views... FOSS debugging utilities don't even come close to the debugging productivity on VS 2022.
Totalview https://totalview.io/ or Ex-Allinea (now Nvidia) - don't know if it's still usable as a 'general' debugger though. https://developer.nvidia.com/allinea-ddt
Both don't work with Rust.
There are also DAP-based integrations, which I have put the effort into using.
https://code.visualstudio.com/docs/typescript/typescript-deb...
https://code.visualstudio.com/docs/nodejs/browser-debugging
The JS-to-TS mapping is handled through source map (so you're 'debugging' the TS code, even though it's JS under the hood).
(also, in case you're not aware, browsers have a builtin debugger in their devtool panel, these also have source map support, but this may require some tinkering)
But all those tiny times add up, over years, decades. And eclipse the time of that afternoon+ spent on learning & configging debuggers in months already.
Don't be me, that senior dev who'd been promising himself for decades to really get down to learning and setting up gdbg or equivalent. And then, once invested, keeps thinking: "I should've done this years ago".
For those use cases where it is tough to see the output (tests, windows services, etc.) I wrote the `rdbg` set of crates. It is essentially identical to `dbg!` and `println!` macros, but delivers messages via a TCP socket to a simple command-line viewer (which can be on the same machine or remote). The design is such that it can be enabled and used the first time within a minute or two for "quick and dirty debugging". It can just as quickly be removed or turned into a no-op with a Rust feature.
Dependency: https://crates.io/crates/rdbg
Viewer: https://crates.io/crates/rdbg-view
EDIT: Apparently I need to update the README as I added the 'msgf' and 'valsf' macros that include auto-flush which is handy for short running programs where explicit flush doesn't work due to failing program/etc.
For ex I recently added a /debug/:map_id endpoint to a server I'm writing that just returns format! ("{:#?}", state.maps.get(id)).
Obviously that'd be completely inappropriate in many cases, but for this one polling the current state via curl was quite handy.
https://marketplace.visualstudio.com/items?itemName=fcoury.r...
Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.
In their example they debug Firefox which I would consider a big application. Of course there are many levels above, and maybe you are talkning about tens of GB of memory usage?
Neovim - Text editor popular for people who like terminals (forked from vim)
RR - Debugging tool that allows you to record failures/errors and play them back, facilitating easier debugging and reproduction (simplified: basically gdb on steroids)
All together (this repository) - A editor plugin for neovim users who use Rust, to use RR directly in neovim.
It should be possible to do the same for Rust.
Needing a debugger still happens once in a while, but languages/projects that are well adapted to this way of thinking really make it extremely uncommon.
But I still find it helpful when you need to check what's wrong in other people's code, since they might not design with types like I do.
Also it can help find why something three crates deep into your dependency tree panicked.
