copacetic@discuss.tchncs.de to Rust@programming.devEnglish · 3 days agoSpeeding up the Rust edit-build-run cycledavidlattimore.github.ioexternal-linkmessage-square12fedilinkarrow-up123arrow-down11cross-posted to: rust@lemmy.mlhackernews@lemmy.bestiver.se
arrow-up122arrow-down1external-linkSpeeding up the Rust edit-build-run cycledavidlattimore.github.iocopacetic@discuss.tchncs.de to Rust@programming.devEnglish · 3 days agomessage-square12fedilinkcross-posted to: rust@lemmy.mlhackernews@lemmy.bestiver.se
minus-squareBB_C@programming.devlinkfedilinkarrow-up1·1 day 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.
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.