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

Rust

5999 readers
20 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
you are viewing a single comment's thread
view the rest of the comments
[–] onlinepersona@programming.dev 1 points 19 hours ago* (last edited 19 hours ago) (2 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

[–] kahnclusions@programming.dev 1 points 58 seconds ago

This is always one of the first things I setup on a project and teach or encourage my teams to do… I’m always surprised how many devs would rather use print statements all the time (not just in Rust, but especially JS/TS) when it only takes like 5 minutes to configure the debugger. Maybe 10 minutes if you need to search how to open the debugging port in Chrome/FF.

[–] BB_C@programming.dev 2 points 18 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.