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

111–120 of 125 posts

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

#111

Post by 0x457 »

nuudlman wrote: post #53
0x457 wrote: post #8

Earlier quoted context omitted.

Enable them when you need to debug. This is for speeding up "edit-build-run" workflows.

It's a lot faster to add a log point in a debugger than to add a print statement and recompile. Especially with cargo check, I really don't see the point of non-debuggable builds (outside of embedded, but the size of debuginfo already makes that a non-starter).

Yes, but we're talking about time spent with "add a print statement and recompile" vs time saved by not including debuginfo on every other build. You have to do that comparison yourself.

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

#112

Post by Vilian »

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?

SSH has the argument that they are older than the specification, now cargo, nah, a lot of application that use ssh hardcoded .ssh, cargo don't have that excuse

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

#113

Post by eddd-ddde »

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.

Ironically the JS debugger is the only one I ever use because it's the only one that "just works".

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

#115

Post by SleepyMyroslav »

jcelerier wrote: post #109
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 s…

Vs story does not match my experience for AAA game projects. First vs always had start debugging without loading any symbols at all. 2nd one can load each one module on demand. 3rd local file cache for symbol servers can be very much warm (ie have most of needed symbols in RAM). 4th if your project is stuck on old Vs version you can still debug with latest version of debugger in many cases. Ie for us there are no limits of how many versions of vs dev has on their pc. It might be only available if org has volume deals with Ms though.

Downloading symbols for first time from network symbol server is long but its not part of debugging cycle, at least after 1st run.

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

#116

Post by Animats »

flohofwoe wrote: post #99
pepa65 wrote: post #97

Earlier quoted context omitted.

You're obviously not a Rust programmer.

Rust only protects from a very small subset of bugs (memory corruption issues and data races) but not from logic bugs which are far more common.

Rust protects against undefined behavior. This is enough that programs either panic in a well-defined way, or continue to run well enough that logging works.

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

#117

Post by stouset »

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.

I use VS Code, and there's an extension that provides a debugger for the languages I use.

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

#118

Post by porridgeraisin »

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 hate XDG. I prefer app/kinds-of-data. If home directory clutter is the problem, I would prefer having a ~/crap folder. So it would be ~/crap/.cargo

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

#119

Post by Arch-TK »

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 thought my comment addresses this specifically.

Yes, it's bad. If you predate the specification then see options 2 (check), 3 (document) or 4 (come up with a new spec for opting in).

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

#120

Post by Arch-TK »

porridgeraisin wrote: post #118
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 hate XDG. I prefer app/kinds-of-data. If home directory clutter is the problem, I would prefer having a ~/crap folder. So it would be ~/crap/.cargo

I am all for a "Please put everything in random sub directories of /" config option for the installer of your linux distribution of choice where / is your home directory, PATH, configuration directory and everything else. But I think you're in the minority.
Post reply on HN