I might be spoiled, since I started working on Windows using Visual Studio back in 1996. The debugger always seemed a fundamental part of developing (an learnin

I might be spoiled, since I started working on Windows using Visual Studio back in 1996. The debugger always seemed a fundamental part of developing (an learning to develop) applications. 10 years later, I was still being spoiled while building Windows CE OS images. There you had KITL to debug (over serial, ethernet or USB) the OS in real time from the IDE. When none of that worked, I purchased myself a Lauterbach probe (6K USD). The debugger IDE is the ugliest thing ever, but it's the most powerful tool around for embedded. Some years later I entered into kernel (Linux) building for embedded. When asked the guru what's there to debug the kernel, the answer I got was "printf". Man, I laughed so hard until I saw his "I'm being serious" face. Then I get used to it, but I still hate it. Again, some years later, I have to build Android images. Again, skimming through thousands of log messages thanks to dmesg and logcat... I still hate it. It seems archaic. The better moments of my current work is going bare-metal, debugging with an IDE, with my 15 euro JTAG plus OpenOCD and Eclipse. I couldn't be happier. In fact, for bare-metal embedded, there is no other way around. There is no printf. You can have it with semihosting or a serial port, but it's painful... it messes up with my timings. I need to debug using an IDE. And GDB from the command line... come on... it's 2021. It can be avoided. Even when I started with Rust for embedded I wanted a full debugging IDE (which I didn't find yet). I want to see how things get arranged in memory (how does a slice or enum look in memory? and, is it possible no one checked this before?) side-to-side with generated assembler. TL;DR, my opinion is that printf might be fine for some desktop development, but as a "I don't have any else to try" resource.