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

101–110 of 125 posts

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

#101

Post by hibbelig »

flohofwoe wrote: post #92
stouset wrote: post #17

Earlier quoted context omitted.

I am comfortable using a debugger, but println debugging is easy, fast, and disproportionately effective for most of my debugging in practice. I reach for a “real” debugger when necessary, but that’s less than 5% of the time.

I wonder, do you use a separate debugger, or a debugger that's integrated into your IDE? "Reaching for a debugger" is just pressing F5 in an IDE. E.g. I keep wondering whether the split between people who can't live without debuggers vs people who rarely use debuggers is actually people who use IDEs versus people who don't.

Data point: I develop in Java and I use IntelliJ. I run everything in debug mode. So it’s really easy for me to enter the debugger.

But I find that if I have to step around more than a handful of times to find the issue then I forget what happened five steps ago. So I teach for print debugging quite often.

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

#102

Post by hibbelig »

kaba0 wrote: post #87
0x457 wrote: post #16

Earlier quoted context omitted.

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.

That’s true but boy howdy does pausing the program at a breakpoint change timing!

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

#103

Post by johnisgood »

childintime wrote: post #95
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…

If you have to blame the developer, blame the OS. Shit drops down from above. Maybe it's just old and crappy.

Blame the OS? Why? And what good would that do? The developers could have used XDG_CONFIG_HOME at the very least.

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

#104

Post by johnisgood »

pjmlp wrote: post #96
flohofwoe wrote: post #79

Earlier quoted context omitted.

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

That is why I found so great that Carmack's opinion on debuggers is similar to ours, at least there is some hope to educate the crowds that worship Carmack's achievements.

Is that crowd getting bigger or smaller though? When he worked for id Software, he was pretty popular in my circle of friends, because we were playing ioquake3 forks that we kept making mods for and so forth.

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

#105

Post by NautilusWave »

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…

So like ~/.ssh/ is bad? Or does it get grandfathered?

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

#106

Post by rascul »

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…

Stop giving me a mix of locations that aren't even used correctly and just put the dot file/directory in my home directory.

Thanks in advance.

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

#107

Post by pjmlp »

johnisgood wrote: post #104
pjmlp wrote: post #96

Earlier quoted context omitted.

That is why I found so great that Carmack's opinion on debuggers is similar to ours, at least there is some hope to educate the crowds that worship Carmack's achievements.

Is that crowd getting bigger or smaller though? When he worked for id Software, he was pretty popular in my circle of friends, because we were playing ioquake3 forks that we kept making mods for and so forth.

I would say among the folks that care about game development and graphics programming, people still listen to him with attention.

Outside that circle, maybe not.

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

#108

Post by ramon156 »

NautilusWave wrote: post #105
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…

So like ~/.ssh/ is bad? Or does it get grandfathered?

I feel like a healthy mix is fine. Just like I wouldn't want my repo to be 90% cache, having 1-2 folders is fine.

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

#109

Post by jcelerier »

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 c++ for debugging a mid-sized app, gdb will sometime take up to 5 min to start (assuming no remote symbol cache used). On fairly powerful hardware - i7 13000-something, 64g of RAM. I have the time to do 15 compile-edit-run cycles adding prints in that time span before I have even reached main() in it. (And I really tried every optimisation, gdb-index, caches, split DWARF etc. It jus is absolutely mind bogglingly slow and sometimes will even just crash when reaching a breakpoint. Same for lldb. Those are just not reliable tools. And I'm not even talking of the MSVS debugger which I once timed to take 18 minutes from "start debugging" to actually showing a window with all the symbol server stuff.

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

#110

Post by seanhunter »

HdS84 wrote: post #98
childintime wrote: post #95

Earlier quoted context omitted.

If you have to blame the developer, blame the OS. Shit drops down from above. Maybe it's just old and crappy.

As a non linux expert I always wonder where to put crap - most places seem not fit for purpose.

There is a standard which you should follow. Here you go https://specifications.freedesktop.org/basedir-spec/latest/
Post reply on HN