I ran into this problem when working with gtk-rs. For every async library that you use, you have to look carefully if it requires a specific runtime. If you want to eg. make a HTTP request with reqwest you need to make sure to spawn a task on a tokio runtime running in the background.

[–] sugar_in_your_tea@sh.itjust.works 6 points 9 months ago* (last edited 9 months ago)

Here's my main takeaway with simpler language:

Rust doesn't provide a way to abstract over async runtimes, so futures need to embed that somehow if they need access to it. So if you try to use functions intended for another runtime, you can get crashes.

This seems like it could be solved by providing an async runtime implementation in std that could be swapped out if desired (like the memory allocator).

[–] syd@lemy.lol 3 points 9 months ago (1 children)

Well, this one goes to my “save but never read” box.

[–] robinm@programming.dev 8 points 9 months ago (1 children)

You shouldn't, it's short and interesting

[–] syd@lemy.lol 1 points 9 months ago

Yep it was good. I also read original JS version article too 😄

[–] robinm@programming.dev 2 points 9 months ago

Interesting idea indeed. I've never used async yet, but I'm always surprised at how the problem space seems to be much more complicated than what it initially looks like.

[–] Vorpal@programming.dev 1 points 9 months ago

The example FileDescriptorPollContext doesn't really work. What if my runtime uses io-uring instead of polling? Those need very different interfaces to be sound. How do you abstract over that.