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

61–70 of 125 posts

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

#61

Post by dgfitz »

grey-area wrote: post #27
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.

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.

Logs are gold. Parsing logs can be very exhausting.

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

#62

Post by nicce »

forrestthewoods wrote: post #31
fmbb wrote: post #19

Earlier quoted context omitted.

> Inserting println statements, compiling, running, inserting more println, and repeating is very inefficient. That all depends on how long it takes to compile and run. > If you learn to use a debugger, set breakpoints, and step through code examining values while you go then the 8 seconds spent compiling isn’t an issue. Meh, it's fine. You still have to set new ones and re-run your code to trigger the reproduction i…

Stepping through code and adding breakpoints is a spectacular way to figure out where to put log statements. Modern code is so abstract that it’s nigh impossible to figure out what the fuck function even gets called just from looking at code.

I guess it depends if you are working with your own code or someone else's. If you work with your own code, you should have pretty good idea already.

Debuggers are pretty good when you want to understand someone else's code.

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

#63

Post by [deleted] »

dgfitz wrote: post #44
bluGill wrote: post #26

Earlier quoted context omitted.

They use printf. Which they claim is faster.

I'm not against printf at all, my lifetime commit history is evidence of that. Do you also think that in the case of a coredump not existing, that printf is faster? Sincere question. I'm having an internal argument with myself about it at the moment and some outside perspective would be most welcome.

[deleted]

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

#64

Post by dgfitz »

ehaliewicz2 wrote: post #52
bluGill wrote: post #26

Earlier quoted context omitted.

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.

I’ve always wondered why embedded devs make less than “JavaScript-FOTM” devs.

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

#65

Post by ffsm8 »

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…

Your serious code isn't performance sensitive if it's a distributed monolith like you're describing.

It's just another wannabe big scale dumbsterfire some big brain architect thought up, thinking he's implementing a platform that's actively being used by millions of users simultaneously, aka Google's or a few social media sites.

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

#66

Post by Arch-TK »

> ~/.cargo/

This reminds me...

STOP putting your shitty dot-directories full of a mix of config, cache and data in my god damned home directory.

Concerned that not doing this will break things? Just check if you've dumped your crap in there already and if not then put it in the right places.

Worried about confusing existing users migrating to other machines? Document the change.

Still worried? How about this: I'll put a file called opt-into-xdg-base-directory-specification inside ${XDG_CONFIG_HOME:-$HOME/.config} and if you find that file you can rest assured I won't be confused.

Thanks in advance!

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

#67

Post by dietr1ch »

dgfitz wrote: post #60
dietr1ch wrote: post #33

Earlier quoted context omitted.

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.

I find them amazing, it's just that printf is unreasonably good given how cheap it is.

If I had the symbols, metadata, powerful debugger engine and a polished UI, I'll take that over printf everyday, but in the average situation printf is just too strong when fighting in mud.

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

#68

Post by freeone3000 »

gooosle wrote: post #56
freeone3000 wrote: post #45

Earlier quoted context omitted.

CLion adds the power of IntelliJ debuggers to Rust. It works exceptionally well.

Does it support evaluating code, in context, while debugging?

Yes*, mostly

It can do any single expression, and the results are better than lldb, but it can’t do multiple statements and not everything in Rust can be one expression; you can’t use {} here

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

#69

Post by freeone3000 »

nicce wrote: post #58
freeone3000 wrote: post #45

Earlier quoted context omitted.

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.

Sure. It’s got breakpoints, and conditional breakpoints, using the same engine as IntelliJ. It’s got evaluate, it’s got expression and count conditionals, it’s got rewind. It has the standard locals view.

Rust support has improved in 2024 pretty strongly (before this year it just shelled out to lldb); the expr parser and more importantly the variable viewer are greatly improved since January.

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

#70

Post by bluGill »

unclad5968 wrote: post #32
bluGill wrote: post #24

Earlier quoted context omitted.

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.

It's one click to set the breakpoint in the ide or one line if you're using gdb from the command line. I'm not sure how printf debugging could be quicker even if you didn't have to rebuild. Having done both, I'd take the debugger any day.

the important time is thinking time and debuggers don't help. Often they hurt because it is so sudctive to set those breakpoints instead of stophing to think about why.
Post reply on HN