Async Interviews

This is a companion discussion topic for the Async Interviews that I am discussing. As the introductory blog post clarifies, the goal of these interviews is primarily to help answer the question, "Now that async-await is stable, what should we do next?" But it's also just to have fun talking about Async I/O and Rust and exploring what the ecosystem has to offer.

Collected links to the blog posts and videos:

8 Likes

Questions from the audience:

  1. Is all this async/await stuff in Rust as confusing as it is in Python?

  2. Should we even be thinking about async if our use cases don't call for it?

  3. How can we avoid all the complexity of async in the normal case when we don't need it?

I ask because I have just wasted a day of my life trying to get data in through an async API and out through a "normal" API in Python.

I want to have stern words with whoever put that complexity into my life for no good reason.

Sorry if all that seems unduly negative. But this does bug me.

1 Like

I have used async/await extensively in both C# and Typescript. In Typescript it was compiled down to ES5 if your target was not ES6, which supports async directly. These compiler created state machines are amazing when you can't afford a "thread per socket" model OR the complexity of callbacks 3 or 4 levels deep in a single threaded language like JS makes the code insane as you attempt to handle both the expected condition and error condition for each function with a callback.

No. If there is no reason the code you are calling would block (i.e. typically is CPU bound), doing anything with async is a waste of time and elevates complexity for no good reason. It also changes your debugging strategies as you can't simply list the threads and see what is in process.

I really like this question. It looks simple but you can approach it from different viewpoints.

Right now we're all used to sync and consider async as "more complex". But in one or two years time, one might well learn async Rust directly - doing a few async projects and knowing a couple of async crates, not necessarily their sync counterparts. For such a person, it may be reasonable to stay with async for another problem that doesn't require it.

Maybe some people in the Python world are already at this point.

That is a good point.

Back in the day, when we did not have threads in our operating system, if we had an operating system at all, we built cooperative multi-tasking systems. I have had a hand in a few of those. They were a kind of "light weight thread system". Everything worked very well and efficiently. Provided everyone was aware of the frame work they were working in. Much like async.

When I speak of the complexity of async/wait I am comparing to the amazing simplicity of building event driven systems in Javascript, in node.js. Basically you have no choice. That is how everything works (almost). The syntax is dead simple. Even if you are using event handlers and call backs rather than async/await.

That made me chuckle. I only know one Python programmer. That problem with async/await I mentioned above is me trying to fix his code for him. And I am no Python programmer!