this post was submitted on 14 Nov 2024
22 points (95.8% liked)

Rust

5999 readers
65 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev
22
Speeding up the Rust edit-build-run cycle (davidlattimore.github.io)
submitted 2 days ago by copacetic@discuss.tchncs.de to c/rust@programming.dev
10 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] onlinepersona@programming.dev 1 points 16 hours ago* (last edited 16 hours ago) (1 children)

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.

I weep for the time lost on debugging with println. Good grief. It's like having access to a time stopping ability and going "nah, I like trying to add a marker and tracing footsteps".

Yes, for multi threaded workloads there aren't many options, but most are single threaded and eschewing a debugger is bonkers to me.

Anti Commercial-AI license

[–] BB_C@programming.dev 2 points 16 hours ago

for multi threaded workloads there aren’t many options

Anyone who actually writes Rust code knows about tracing my friend.

We also have the ever useful #[track_caller]/Location::caller().

And it's needless to say that dbg!() also exists, which is better than manual printing for quick debugging.

So there exists a range of options setting between simple printing, and having to resort to using gdb/lldb (possibly with rr).

But yes, skipping debugging symbols was a bad suggestion.