> And, nobody really steps through code anymore.

I don't follow. What other technique is in, compared to code stepping?

Sometimes I put a breakpoint in and step thru code to help me figure if something is working properly or maybe live-inspect the return value of something that comes from the outside world. Maybe I'm missing some new fundamental technique to dev/debug?

Thanks in advance. (genuine question)

I have seen very few people actually hook up a debugger and step through code lately. This is particularly pronounced in many of the functional idioms that are making it into java and similar languages. Stepping through a loop is now much more involved, entering the stream is a step in, not just a step.

I don't actually have a lot of experience with the rust world, but the main complaint with macros is typically that you can't step through them easily.

With my getting downvoted, I'm assuming I'm wrong and that step debuggers are more common in rust than I was assuming. I think that makes me happy. If anyone has a good video demonstrating this level of tooling, I'd be interested.

"printf debugging" vs "debugging" is an eternal struggle. Many people do both, in both C++ and Rust. There are many, many essays written about the pros and cons of both approaches.

Rust as a project is investing heavily in working towards excellent debugger support, because people do use it.

Debugging in CLion with gdb and the intellij-rust plugin is already quite pleasant.

It even works remotely attached to bare metal embedded projects on stm32 microcontrollers!

Unfortunately debugging isn't available with intellij-rust in the free IDEA community edition.

How well does it work with heavy use of macros? Specifically, what does it mean to "step into" a heavily macro based section? I'd be very interested in seeing examples.

I do, but Visual Studio debugger lets me chose what I step into to.

I think it is fair that my comment was clearly all encompassing where it should not have been. I am curious on the numbers, though. Just anecdotally, I have seen very few people use a step debugger.

Some of it may be situational. With how many microservices I'm dealing with, "stepping into" a call really needs to jump to another process quite often.

Anyone have numbers, by chance, on how many folks actually use a lot of these features?

Visual Studio also does remote debugging, including for services running on Azure, and recently introduced across containers.

Usually the problema is that many developers never learned what a visual debugger is capable of, and the typical command line interface in UNIX leaves little room for exploration if people aren't curious to learn about them.

For example, many aren't aware that gdb has a TUI that eases the experience.

I know you can do remote debugging. I mean the case where you have a breakpoint in one service, and it calls to another service. You can't really "step into" that. Best you can do is connect to both services and have cooperating breakpoints.

But, really, this is something I've never actually done. Reasoning about how the system should behave has been enough to get me by.

A scenario I have used it a lot was in debugging cooperating processes in UNIX, a couple of years ago.

When some condition took place, the problematic process would break into the debugger, while the others would be parked waiting for me to attach to them.