Async Rust: Portability and Interoperability - Nick Cameron - Rust Linz, April 2022

Async Rust: Portability and Interoperability

I'll talk about the portability and interoperability initiative of the async working group, an attempt to make async programming in Rust less tied to specific runtimes and improve interoperability in the async ecosystem.

I'll cover some of the problems with async programming today, what the initiative will try to achieve, and some detail about current work on async IO traits (Read, Write, etc).

No async programming experience required!

About Nick Cameron

Rust at Microsoft. Previously: Rust core team, distributed databases at PingCAP, Firefox graphics and layout, research in PL and type systems. He/him.

[markmcdonnell]

Loved the "devil's advocate" approach to thinking like a new rust async user and not knowing a bunch of context. It really highlights how bad the docs actually are there.

[WhatsMikeUpTo]

Nick, you literally described my thought process as a beginner in the first ten minutes of the video. It was uncanny how well it paired up. At the end of the talk I did think about using another programing language for that reason. But, I am going to continue my Rust journey knowing that it will improve 😊

[l-const]

really liked your presentation and the commentary/frustration when reading the async rust book!!!

[martinfrances]

really good explanation of the issues.

[sligit]

Fantastic. It's really great to see that the WG is looking to address all these issues.

[altairbueno]

Great talk! Never thought that async rust io traits where so difficult

[TheMsksk]

Very insightful talk and vey well presented. I coukd follow whatbwas being said inspite of being a complete Rust novice. Thank you!

[nirmalyasengupta]

Very useful piece of information. Where may I find more information on the topic and the ongoing work? Is there an avenue to put forward my opinion on this?

[kevinking]

One thought on the dangling pointer issue re. the Completion model: could a Drop impl on a completion-based future be used to cancel the read at the OS level?

[peternierop]

OMG... I had exactly that reaction when first hopefully diving in the async stuff... I felt so dumb... and that while have written an OS in 286. So indeed it is just the document.

[pashadia]

I think the async runtime should be just like the memory allocator: you can change it if you really want, but most people shouldn't really need to, and just benefit from a good default.

[peperudpeperudski]

Very good explanation and presentation. I wasn’t loosing my mind. Thanks! IMO some form of straightforward async/await that “just works” should be baked into the language itself. If this does not suit you - then go more specialized.

[garma]

This is a great description of my experience with async/await. There needs to be more clarity in the ecosystem. Someone should make a few choices IMHO, and streamline the naming. 

It's fine to provide choice, but not in a way that it hurts situations where the choice doesn't matter. My challenge very often is to find ways to let the different systems play nice together when using crates that use different runtimes.