Several different motivating factors have aligned for me to dust off something long on my to-do list of software development skill-building: learning then getting hands on with the async/await programming pattern. In this world of multitasking, multithreading, and multicore CPUs communicating with each other over the network, asynchronous programming is required everywhere. However, historically my programming projects have either (1) not dealt with asynchronous behavior, as it was handled elsewhere or (2) had to be written explicitly and unable to use syntactic niceties like async/await.

I knew experience structuring code for async/await is a gap in my toolbox, but I never had enough of a motivation to sit down and patch that gap until now. And like every new area of knowledge, it helped to get some more background on this development in programming languages before I dove in. Contributors to Wikipedia credited futures and promises as the theoretical research foundation where this work began, but it has since evolved through several forms until there was consensus async/await pattern was the way to go.

I don't know which programming languages first put the theory into practice, but I personally first learned of this evolution from JavaScript introducing futures and promises some years ago. It sounded interested but I was not impressed by how it was implemented at the time, and apparently enough people agreed that JavaScript has now adapted them to the newer async await pattern. Available to the web development world both on the server side via Node.JS and on the client side via modern browsers.

I haven't played with JavaScript as much as I've wanted, it's still on the to-do list. I've been spending more time on the other modern language darling: Python. I had never used async/await with Python, but it is there so I'll be able to use it in Python once I learn enough to make it a part of my programming toolbox.

One concern with novel programming techniques is that people may get bored and move on to the next shiny object. It is definitely a worry with ideas under rapid evolution, so how does a grumpy old programmer know something has sufficiently stabilized? By seeing if it's in the latest version of C++, of course. And while the answer is a "no" today, it appears to be more of a "not yet" which gives me confidence in stability. It may still evolve, but I am unlikely to get whiplash from future developments.

Confident that it's not going to disappear tomorrow, I surveyed the field of options and decided to start with C# as my first exploration into this programming pattern. Also called TAP or Task-based Asynchronous Pattern in Microsoft's documentation. Part of this decision was informed by learning why Microsoft was motivated to recommend it.