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

71–80 of 125 posts

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

#71

Post by bluGill »

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.

Most of my time with printf degugging is spent trying to reason about the code not compiling.

though you should note that I'm repeating their claims. What I think is hidden.

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

#72

Post by pvinis »

Arch-TK wrote: post #66

> ~/.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 pu…

I would upvote at least 10 times if I could.

This!

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

#73

Post by robdar »

Aurornis wrote: post #10
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…

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.

printed/println debugging works if you wrote the code or have a good idea of where to go.

I frequently find myself debugging large unfamiliar code bases, and typically it’s much easier to stick a breakpoint in and start following where it goes rather than blindly start instrumenting with print statements and hoping that you picked the right code path.

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

#74

Post by rascul »

canucker2016 wrote: post #49
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.

But what source code debuggers did they have available? Other than gdb, I can't name any Unix C source code debuggers. I believe they were working on Unix before GDB was created (wikipedia says gdb was created in 1986 - https://en.wikipedia.org/wiki/Gdb ). Plan 9 has acid, but from the man page and english manual, the debugger is closer to cli/tui than gui. see https://9fans.github.io/plan9port/man/man1/acid.html and…

Looks like there was an adb in 1979 which is supposedly the successor to db.

https://en.wikipedia.org/wiki/Advanced_Debugger

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

#76

Post by eviks »

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…

> Using a debugger to step through the code is a huge timesaver.

This is too slow and manual of a process to be a huge timesaver, you'd need a "time-travel" debugging capability that eliminate these to save time

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

#77

Post by DylanSp »

zerd wrote: post #51

This post is from February, any interesting changes/improvements since then? Progress on “wild”?

Looks like he's been continuing to work on it.

GitHub repo: https://github.com/davidlattimore/wild

List of his blog posts, a couple of which are about wild: https://davidlattimore.github.io/

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

#78

Post by AlotOfReading »

bippihippi1 wrote: post #46
viraptor wrote: post #36

Earlier quoted context omitted.

Depends what you're working on. Stopped in an unfortunate place? That one element didn't get turned off and burned out. Or the motor didn't stop. Or the crucial interrupts got missed and your state is now reset. Or...

are there debugging tools specifically for situations like that? do you just write code to test manually? How do you ensure dev builds don't break stuff like that even without considering debugging?

You ensure dev builds don't break stuff like that with realtime programming techniques. Dev tools exist and they're usually some combination of platform specific, expensive, buggy, and fragile.

printf and friends are fantastic when applicable. Sometimes the cost to even do an async print or even building in any mode except stripped release is impossible though, which usually leads to !fun!.

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

#79

Post by flohofwoe »

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 also don't get it, debuggers as integral part of the programming workflow are a productivity multiplier. It does seem to be a fairly popular opinion in some programmer circles that step-debugging is useless, but I guess they never really used a properly integrated debugger to begin with (not a surprise tbh if all they know is gdb in the terminal).

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

#80

Post by flohofwoe »

eminence32 wrote: post #43
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…

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?

Post reply on HN