I recently setup dap-mode for Rust with it’s built-in setup functions, and not knowing which I’d prefer, I setup GDB, LLDB, and microsoft’s c++ whatever. I tried to get dap-mode alternative dape to work with the same binaries (eg. rust-gdb), but only got complete thread info (and no timeouts) with the codelldb adapter. Anyway, I got the vague impression that GDB’s tooling is the more stable, featureful, and bespoke incumbent, but that LLDB has a better arch. and is catching up. I really value knowing fuller stories and scopes about the tools that I use and am glad to have come across this insightfully in-the-weeds perspective.
(while on the subject, #buglog, i also learned that one of rustic-mode’s setup commands curls to bash [via ~/.local/bin], from its own source repo, without a hash, every time you run it – lovely package but i’ll be wondering why that “resource” pattern was applied until I find time to patch it out)
This is great, thanks!
I recently setup dap-mode for Rust with it’s built-in setup functions, and not knowing which I’d prefer, I setup GDB, LLDB, and microsoft’s c++ whatever. I tried to get dap-mode alternative dape to work with the same binaries (eg. rust-gdb), but only got complete thread info (and no timeouts) with the codelldb adapter. Anyway, I got the vague impression that GDB’s tooling is the more stable, featureful, and bespoke incumbent, but that LLDB has a better arch. and is catching up. I really value knowing fuller stories and scopes about the tools that I use and am glad to have come across this insightfully in-the-weeds perspective.
(while on the subject, #buglog, i also learned that one of rustic-mode’s setup commands curls to bash [via ~/.local/bin], from its own source repo, without a hash, every time you run it – lovely package but i’ll be wondering why that “resource” pattern was applied until I find time to patch it out)