If Writing Coroutines Goes Over My Head, Where Do I Even Begin with Debugging?

Do we even stand a chance if Kernighan's law holds true: "Debugging is twice as hard as writing the code in the first place"? The situation seems bleak at first. Even years after coroutines were introduced as a language feature, we're still missing the promised software libraries and standardized terminology that were supposed to make things easier. We've finally settled on std::generator-viewed by some as a divine promise-but it's not even truly asynchronous, which is why it rightfully belongs in the Ranges library. At least we now have yield and the lesser-known yield from from Python. However, asynchronous building blocks like std::task or std::lazy still feel like distant dreams.

Boost.Asio and Boost.Cobalt could become our version of asyncio, providing a generator with different semantics than std::generator, a task, and a runtime. We now get a taste of what it's like to be JavaScript developers navigating the asynchronous world!

Coroutines are not easy. We've already tried easy with Cilk+, and it wasn't what we wanted. Coroutines aren't like iterators, with boilerplate nobody dares to write themselves. Everything is included because we want it all and it's impossible to achieve consensus on the details. std::generator is just one use case and doesn't shed light on the bigger picture nor does it illuminate a coroutines full potential. Now is the time to identify our own use cases.

In this session, we'll explore coroutines in the debugger, tackling them the way we often learn code nowadays: by stumbling through it. Together, we'll discover that in most cases, only a few straightforward principles are key-and it's not nearly as complicated as it might first appear.