>> 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.
> 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
https://en.wikipedia.org/wiki/No_true_Scotsman
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.