Live data from Hacker News

Rust, RR, Neovim: A perfect debug combination

github.com

31–40 of 102 posts

Re: Rust, RR, Neovim: A perfect debug combination

#31

[flagged]

I started watching [3]. I have no stakes in this, but a lot of stuff I should be enraged about... I'm just not? Doesn't look fundamentally different to Debian or Firefox trademark policies.

I guess it is an abrupt change in trademark enforcement for Rust.

Re: Rust, RR, Neovim: A perfect debug combination

#32

Only if you're debugging tests. Unfortunately using rr to debug a bigger application with lots of RAM access is not feasible.

Is that true? I genuinly have no experience with it. 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?

I haven't tried with FF personally, but the issue I have is that the traces are huge and reverse execution through memory-intensive codepaths takes a very long time, making the experience really slow. Or you can run a release build (with optimizations), in which case everything gets inlined, your asserts get nuked, and you're unable to inspect state well enough to figure out what's going on. In most cases, an ordinary debugger provides a better UX for me, but for the odd memory bug untraceable by normal hardware breakpoints in a traditional forward debugger, it comes in handy.

Re: Rust, RR, Neovim: A perfect debug combination

#35

Anyone got other useful tools for debugging within (neo)vim? Just seamlessly putting down breakpoints, stepping through code execution, and getting a fully fledged debugging UI experience (a la Visual Studio or Remedy BG)? This is possibly the only thing I miss from developing on Windows, and it's a shame! EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.

I tried nvim-dap but it is somewhat clunky, unintuitive to use. Turn out that that using delve, gdb, pydb directly on the command line is fine, I don't really need editor integration.

Re: Rust, RR, Neovim: A perfect debug combination

#37
post #3

Investing in a good debugging tool and knowing your way around using it well, makes all the difference.

I've been using Rust on Windows, LLDB is just pain. Not being able to see content of enums is a show stopper, luckily VSCode has C++ debugger by Microsoft that works flawlessly.

Re: Rust, RR, Neovim: A perfect debug combination

#38
post #31

[flagged]

I started watching [3]. I have no stakes in this, but a lot of stuff I should be enraged about... I'm just not? Doesn't look fundamentally different to Debian or Firefox trademark policies. I guess it is an abrupt change in trademark enforcement for Rust.

Just ignoring that it is fundamentally gross and pointless, which some people don't understand somehow, consider the practical implications. I can't casually make a youtube video or blog article teaching about Rust without worrying about trademarks if I use the word. Hundreds of rust libraries have Rust in the name and would be in violation of this policy the second it changed, etc.

Re: Rust, RR, Neovim: A perfect debug combination

#39

Anyone got other useful tools for debugging within (neo)vim? Just seamlessly putting down breakpoints, stepping through code execution, and getting a fully fledged debugging UI experience (a la Visual Studio or Remedy BG)? This is possibly the only thing I miss from developing on Windows, and it's a shame! EDIT: I specified 'within vim' but actually I'd be down for standalone Linux app recommendations too.

VSCode with the CodeLLDB or MS C/C++ extensions both usually work out of the box for debugging most compiled languages (so far I tried C/C++, Rust and Zig), but compared to proper Visual Studio it's very bare bones (especially the variable view panel).

Re: Rust, RR, Neovim: A perfect debug combination

#40
post #9

Funny thing is that thanks to rust compiler I never had a need to debug my code :-)

It may be true that this holds for issues related with out-of-bounds accesses or temporal safety errors, but nothing eludes your application to contain logic bugs. In fact, whenever the application is big enough and you spot a logic error, the debugging burden is still there. Good part is that the debugging utilities for C/C++ are still helpful for Rust programs.

Usually, understanding the type system changes you code/thinking about business logic too. That stems from the habit of thinking about how to check your expected behaviour before implementing it.

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.

Post reply on HN