This post is from February, any interesting changes/improvements since then? Progress on “wild”?
Speeding up the Rust edit-build-run cycle
51–60 of 125 posts
Re: Speeding up the Rust edit-build-run cycle
#52Earlier quoted context omitted.
What if the program doesn’t crash? It just black-boxes the data incorrectly? I can find that error infinitely faster with a debugger.
They use printf. Which they claim is faster.
printf isn't faster if you want to single step through code to find math precision errors.
I've had to do that on a embedded system that didn't support debugging. It was hell.
Re: Speeding up the Rust edit-build-run cycle
#53Not linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?
Enable them when you need to debug. This is for speeding up "edit-build-run" workflows.
It's a lot faster to add a log point in a debugger than to add a print statement and recompile. Especially with cargo check, I really don't see the point of non-debuggable builds (outside of embedded, but the size of debuginfo already makes that a non-starter).
Re: Speeding up the Rust edit-build-run cycle
#54> If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger You lost me here. Using a debugger to step through the code is a huge timesaver. Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the…
Is it really saving time or are you not thinking enough about what is wrong until you stumble on an answer? I can't answer for you but I find that the forced wait for build also forces me to think and so I find the problem faster. It feels slower though but the clock is the real measure.
Sometimes "just thinking harder" works, but often not. A debugger helps you understand what your code is actually doing, while your brain is flawed and makes flawed assumptions. Regardless of who you are, it's unlikely you will be manually evaluating code in your head as accurately as gdb (or whatever debugger you use).
I think a lot of linux/mac folks tend to printf debug, while windows folks tend to use a debugger, and I suspect it is a culture based choice that is justified post hoc.
However, few things have been better for my code than stepping through anything complex at least once before I move on (I used to almost exclusively use printf debugging).
Re: Speeding up the Rust edit-build-run cycle
#55Earlier quoted context omitted.
> because debugger breaks hardware What? Seems like you’re talking about embedded but I’ve done a lot of embedded projects in my time and I’ve never had a debugger that breaks the HW.
On embedded, debuggers almost never work until you get to really expensive ones. In addition, debuggers tend to obscure the failure because they turn on all the hardware which tends to make bugs go away if they are related to power modes. One of my "best" debuggers for embedded was putting an interactive interpreter over a serial interface on an interrupt so I could query the state of things when a device woke up eve…
I’ve worked with many M3s and M4s and some Cypress microchips and the JTAG debuggers always worked fine as far as I recall. There were some vendors that liked to force you to buy really expensive ancillary HW but a) there was plenty of OSS that worked fairly well b) you could pick which vendor you went with.
Re: Speeding up the Rust edit-build-run cycle
#56Earlier quoted context omitted.
In my experience Java debuggers are exceptionally powerful, much more so than what I've seen from C/C++/Rust debuggers. If I'm debugging some complicated TomEE application that might take 2 minutes to start up, then I'm absolutely reaching to an IntelliJ debugger as one of my first tools. If I'm debugging some small command line application in Rust that will take 100ms to exhibit the failure mode, there's a very good…
CLion adds the power of IntelliJ debuggers to Rust. It works exceptionally well.
Does it support evaluating code, in context, while debugging?
Re: Speeding up the Rust edit-build-run cycle
#57Earlier quoted context omitted.
On embedded, debuggers almost never work until you get to really expensive ones. In addition, debuggers tend to obscure the failure because they turn on all the hardware which tends to make bugs go away if they are related to power modes. One of my "best" debuggers for embedded was putting an interactive interpreter over a serial interface on an interrupt so I could query the state of things when a device woke up eve…
I’ve worked with many M3s and M4s and some Cypress microchips and the JTAG debuggers always worked fine as far as I recall. There were some vendors that liked to force you to buy really expensive ancillary HW but a) there was plenty of OSS that worked fairly well b) you could pick which vendor you went with.
All of those chips you mentioned will turn on all the units at full power when you connect a debugger to them.
And the OSS stuff never works correctly. I wind up debugging the OSS stuff more than my own hardware. And I've used a LOT of OSS (to the point that I wrote software to use a Beaglebone as my SWD debugger to work around all the idiocies--both commercial and OSS).
Re: Speeding up the Rust edit-build-run cycle
#58Earlier quoted context omitted.
In my experience Java debuggers are exceptionally powerful, much more so than what I've seen from C/C++/Rust debuggers. If I'm debugging some complicated TomEE application that might take 2 minutes to start up, then I'm absolutely reaching to an IntelliJ debugger as one of my first tools. If I'm debugging some small command line application in Rust that will take 100ms to exhibit the failure mode, there's a very good…
CLion adds the power of IntelliJ debuggers to Rust. It works exceptionally well.
Do you have more information about this?
Last time I debugged Rust with CLion/RustRover, the debugger was the same as VSCode uses.
Re: Speeding up the Rust edit-build-run cycle
#59>Debug information tends to be large and linking it slows down linking quite considerably. If you’re like many developers and you generally use println for debugging and rarely or never use an actual debugger, then this is wasted time. Interesting. Is this true? In my work (java/kotlin, primarily in app code on a server, occasional postgres or frontend js/react stuff), I'm almost always reaching for a debugger as an…
Debugging in Rust is substantially less common for me (and probably not only for me) because it is less often needed and more difficult - many things that are accessible in interpreted world don't exist in native binary. I do care about usable tracebacks in error reports though.
Main challenge with debuggers in Rust is to map the data correctly into the complex type system. For this reason I rarely use debuggers, becase dbg! is superior in that sense.
Re: Speeding up the Rust edit-build-run cycle
#60Earlier quoted context omitted.
What if the program doesn’t crash? It just black-boxes the data incorrectly? I can find that error infinitely faster with a debugger.
Printf debugging excels on environments where there's already good logging. Here I just need to pinpoint where in my logs things have already gone wrong and work my way backwards a bit. You could do the same with a debugger setting up a breakpoint, but the logs can better surface key application-level decisions made in the process to get to the current bad state. On a debugger I need to wind back on all functions, wh…
I appreciate your candor.
I really value debuggers. I have spent probably half my career solving problems that weren’t possible to solve with a debugger. When I can fall back on it, it helps me personally quite a bit.