• onlinepersona@programming.dev
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    edit-2
    2 days ago

    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

    • Aras@feddit.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 hours ago

      I have to admit I still readily reach for dbg! to narrow down where the problem is happening (instead of endlessly stepping through), especially in async. But when I do I put in one or two a function and upto one an await. Then I make a breakpoint before that and debug if I didn’t find it by just a short look.

    • kahnclusions@programming.devM
      link
      fedilink
      arrow-up
      1
      ·
      21 hours 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
      link
      fedilink
      arrow-up
      2
      ·
      2 days 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.