Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up the Rust edit-build-run cycle

davidlattimore.github.io

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Speeding up the Rust edit-build-run cycle

#81

Post by flohofwoe »

Animats wrote: post #30
ryangs wrote: post #5

>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…

The only time I use a debugger with Rust is when unsafe code in some library crate messes up. My own code has no "unsafe". I have debug symbols on and a panic catcher that displays a backtrace in a popup window. That covers most cases. Rust development is mostly fixing compile errors, anyway. Once it compiles, it often works the first time. What matters is compile time for error compiles, which is pretty good. Increm…

Debuggers are not only useful for actual debugging as in 'finding and fixing bugs', they are basically interactive program state explorers. Also "once it compiles, it works" is true for every programming language unless you're a complete newbie. The interesting bugs usually only manifest after your code is hammered by actual users and/or realworld data.

Re: Speeding up the Rust edit-build-run cycle

#82

Post by kaba0 »

flohofwoe wrote: post #80
eminence32 wrote: post #43

Earlier 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…

> much more so than what I've seen from C/C++/Rust debuggers. ...have you ever used the Visual Studio integrated debugger for C/C++ instead of 'raw' gdb/lldb without a UI frontend?

I mean, even then c/CPP will optimize out stuff and you won't get as nice one-to-one mapping as you do with eg. Java.

Re: Speeding up the Rust edit-build-run cycle

#83

Post by flohofwoe »

saurik wrote: post #20
Aurornis wrote: post #7

> 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…

Engh... I used to rely on a debugger a lot 25 years ago when I was learning to program, and was extremely good at making it work and using its quirks; but, I was building overly-simplistic software, and it feels so rare of a thing to be useful anymore. The serious code I now find myself actually ever needing to debug, with multiple threads written in multiple languages all linked together--code which is often perform…

I wouldn't even start a new project before figuring out a proper debugging strategy for it. This also includes not using languages or language features that are not debuggable (stepping from one compiled language into another usually isn't a problem btw, debug information formats like DWARF or PDB are language-agnostic).

Re: Speeding up the Rust edit-build-run cycle

#84

Post by kaba0 »

dietr1ch wrote: post #33
dgfitz wrote: post #23

Earlier 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…

Why not both? For any sufficiently complex app you will have some form of logging either way, and then you can further pinpoint the issue with a debugger.

Also, debuggers can do live evaluation of expressions, or do stuff like conditional breakpoints, or they can just simply add additional logs themselves. They are a very powerful utility.

Re: Speeding up the Rust edit-build-run cycle

#85

Post by flohofwoe »

jesse__ wrote: post #41
ryangs wrote: post #5

>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…

I came here to write exactly this .. if I was drinking something I would have spit it everywhere laughing when I read it. I guess 'many developers' here probably refers to web developers who don't use the debugger, cause it's mostly useless/perpetually broken in JS land ..? I rely heavily on the debugger; can't imagine how people work without one.

The debuggers integrated into web browsers are actually really good, about the same level as most IDE-integrated debuggers.

Re: Speeding up the Rust edit-build-run cycle

#86

Post by flohofwoe »

bippihippi1 wrote: post #42
jesse__ wrote: post #41

Earlier quoted context omitted.

I came here to write exactly this .. if I was drinking something I would have spit it everywhere laughing when I read it. I guess 'many developers' here probably refers to web developers who don't use the debugger, cause it's mostly useless/perpetually broken in JS land ..? I rely heavily on the debugger; can't imagine how people work without one.

when you write async JS code the debugger essentially adds no value over printing

Not in my experience, async JS/TS code is perfectly fine debuggable (at least with setting a breakpoint here and there).

Re: Speeding up the Rust edit-build-run cycle

#87

Post by kaba0 »

0x457 wrote: post #16
Aurornis wrote: post #10

Earlier quoted context omitted.

println debugging is where everyone starts. Some people never graduate to knowing how to use a debugger. Debugging through log data still has a place, of course. However, trying to do all of your debugging through println is so much harder, even though it feels easier than learning to use a debugger.

To be fair, if your code is multithreaded and sensitive to pauses, it becomes harder to debug with a debugger. Ultimately, if you have a good logging setup and kinda know where the issue is a quick log message could be faster than debugging if all you want to do is look a variable value.

Logging can change timing issues though. There are too many cases where an added log statement "fixed" a race condition, simply by altering the timing/adding some form of synchronization inherent in the logging library.

Re: Speeding up the Rust edit-build-run cycle

#88

Post by flohofwoe »

kaba0 wrote: post #82
flohofwoe wrote: post #80

Earlier quoted context omitted.

> much more so than what I've seen from C/C++/Rust debuggers. ...have you ever used the Visual Studio integrated debugger for C/C++ instead of 'raw' gdb/lldb without a UI frontend?

I mean, even then c/CPP will optimize out stuff and you won't get as nice one-to-one mapping as you do with eg. Java.

That's why the debug build config one uses during development only does little to no optimizations.

Re: Speeding up the Rust edit-build-run cycle

#89

Post by vbezhenar »

vlovich123 wrote: post #21
vbezhenar wrote: post #18

Earlier quoted context omitted.

1. Skipping some optimizations to build faster. 2. Conditionally compiling some code like logging (not sure if matters for typical Rust projects, but for embedded C projects it's typical). 3. Conditionally compiling assertions to catch more bugs. I'm using logs, because debugger breaks hardware. Very rarely do I need to reach debugger. Even when hard exception occurs, usually enough info is logged to find out the roo…

> 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.

I mean that stopping execution will often break software logic, for example BLE connection will time out, SPI chip will stop communicate because of lack of commands, watchdog will reboot the chip, etc. And then the whole program will not work as expected, so debugging it will not make further sense. Sorry for miscommunication, I did not mean that hardware physically breaks. It might be possible to solve some of those issues, but generally printing is enough, at least that was my experience.

Re: Speeding up the Rust edit-build-run cycle

#90

Post by flohofwoe »

bluGill wrote: post #26
dgfitz wrote: post #23

Earlier 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.

Faster than pressing F9 (to set a breakpoint on the current line) and then F5 (to start into the debugger)?

Printf-debugging has its uses, but they are very niche (for instance when you don't have access to a properly integrated debugger). Logging on the other hand is useful, but logs are only one small piece of the puzzle in the overall debugging workflow - usually only for debugging problems that slipped into production and when your code runs on a server (as opposed to a user machine).

Post reply on HN