> Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison
It's often hard to run a stepping debugger when you have an embedded hardware
at hand. It's equally hard to run such a debugger when you have multi-threaded
code. And the same stands for virtually any system that works with network
directly, where timeouts are plentiful.
Also, good luck with a debugger in this modern architecture of microservices
that happens to be hype nowadays.
> It's often hard to run a stepping debugger when you have an embedded hardware at hand.
Totally true. But that's a pretty rare situation.
> It's equally hard to run such a debugger when you have multi-threaded code.
Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another. The former is trivial; reduce the task pool size to a single thread. The latter is definitely harder, but modern tooling (I'm partial to VS2017's Threads window) makes this a much more achievable thing; you can break across all of them and step between them effectively.
> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
I find myself debugging in environments where I can control timeouts, but if you can't, yeah, this is totally a problem. Leaving a service paused for ~3-5 minutes while I poke at it doesn't drop connections with my dev configs, though.
> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
"Doctor, it hurts when I do this..."
If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice--you have a monolith that communicates over pipes rather than function calls, and that's strictly worse in the first place.
>> It's often hard to run a stepping debugger when you have an embedded hardware at hand.
> Totally true. But that's a pretty rare situation.
I know it's rare to work with embedded systems if you don't work with
embedded systems. Though when you do work with them, this "rare situation"
suddenly becomes prevalent.
>> It's equally hard to run such a debugger when you have multi-threaded code.
> Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another.
It all works well until it doesn't. That is, until you need two threads to
communicate with each other (otherwise, why are they even running in the same
process?).
>> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
> I find myself debugging in environments where I can control timeouts, [...]
All of them? My simplest cases have dozen timeouts one behind the other, at
different levels of the stack. Even though I potentially can set them all,
it's all very tedious. Not to mention that the timeouts can interact in
non-trivial ways, so it's often hard to track all of them.
>> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
> If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice
Also, I haven't said that "you can't effectively stub out an environment".
There are other difficulties around debugging microservices, like mentioned
before controlling timeouts everywhere.
It's often hard to run a stepping debugger when you have an embedded hardware at hand. It's equally hard to run such a debugger when you have multi-threaded code. And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.