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

21–30 of 125 posts

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

#21

Post by vlovich123 »

vbezhenar wrote: post #18
nuudlman wrote: post #4

Not linking debug info must be some kind of sick joke. What is the point of a debug build without symbols?

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.

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

#22

Post by bluGill »

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…

Depends on the developer. in the Practice of Programming https://en.m.wikipedia.org/wiki/The_Practice_of_Programming by Brian W. Kernighan and Rob Pike they say they use debuggers only to get a stack trace from a core dump and use printf for everything else. You can disagree but those are known very good programmers.

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

#23

Post by dgfitz »

bluGill wrote: post #22
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…

Depends on the developer. in the Practice of Programming https://en.m.wikipedia.org/wiki/The_Practice_of_Programming by Brian W. Kernighan and Rob Pike they say they use debuggers only to get a stack trace from a core dump and use printf for everything else. You can disagree but those are known very good programmers.

What if the program doesn’t crash? It just black-boxes the data incorrectly? I can find that error infinitely faster with a debugger.

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

#24

Post by bluGill »

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…

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.

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

#25

Post by tel »

Just my lack of experience here, but I'm trying to verify I'm successfully using sold. The mold linker claims it leaves metadata in the .comment section, but on mach-o does that exist? Is there a similar evaluation command using objdump as the mold readelf command?

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

#26

Post by bluGill »

dgfitz wrote: post #23
bluGill wrote: post #22

Earlier quoted context omitted.

Depends on the developer. in the Practice of Programming https://en.m.wikipedia.org/wiki/The_Practice_of_Programming by Brian W. Kernighan and Rob Pike they say they use debuggers only to get a stack trace from a core dump and use printf for everything else. You can disagree but those are known very good programmers.

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.

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

#27

Post by grey-area »

dgfitz wrote: post #23
bluGill wrote: post #22

Earlier quoted context omitted.

Depends on the developer. in the Practice of Programming https://en.m.wikipedia.org/wiki/The_Practice_of_Programming by Brian W. Kernighan and Rob Pike they say they use debuggers only to get a stack trace from a core dump and use printf for everything else. You can disagree but those are known very good programmers.

What if the program doesn’t crash? It just black-boxes the data incorrectly? I can find that error infinitely faster with a debugger.

Your existing logs will tell you roughly where and you just insert some more log lines to check the state of the data.

Depends how fast your build/run cycle is and how many different prcocesses/threads whether a debugger will be faster/easier but a lot of it just comes down to preference. Most time spent debugging for me at least is spent thinking about the probable cause then choosing what state to look at.

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

#28

Post by cmontella »

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…

Trace debugging can be inefficient, but it's also highly effective, portable between all languages, and requires no additional tooling. Hard to beat that combo.

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

#29

Post by fiedzia »

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…

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.

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

#30

Post by Animats »

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.

Incremental compile time for my metaverse client is 1 minute 8 seconds in release mode. That's OK. Takes longer to test a new version.

Post reply on HN