Some musings on the async ecosystem and compatibility between async-std and tokio... 1/15
-
Show this thread
-
When the async-std runtime was first introduced, some were worried that the async ecosystem would get split into two: one based on tokio and one based on async-std. Now I'm working on the third major runtime. Very soon we'll have a lot of different runtimes to choose from. 2/15
1 reply 2 retweets 5 likesShow this thread -
But remember, the Future trait and the futures crate have always been intentionally designed to be completely agnostic to the underlying runtimes. So there shouldn't be any fragmentation, no matter how many runtimes there are. 3/15
1 reply 1 retweet 5 likesShow this thread -
To avoid the ecosystem split, async libraries should not depend on async-std or tokio. Only binaries should use a runtime as a dependency. 4/15
2 replies 0 retweets 9 likesShow this thread -
Replying to @stjepang
Unfortunately this is completely unrealistic in practice. Most systems cannot be written this way.
1 reply 0 retweets 1 like -
Replying to @mitsuhiko
Yeah, it's a sad state of affairs. I'm suggesting some workarounds for self-contained async crates and I'll also admit this is not always a viable solution. But, async-h1 did figure out a simple, runtime-independent solution for HTTP clients and servers, which gives me some hope.
2 replies 0 retweets 0 likes -
Replying to @stjepang
I’m thinking once the async craze dies down we will be somewhere where the world looks a bit different. Don’t think picking the excecutor will be our problem in two years. One ecosystem will win.
1 reply 0 retweets 1 like -
Replying to @mitsuhiko
I hope not. In fact, I want to build a world where we have thousands of different runtimes. :) One of the core design goals behind futures is that they're executor-agnostic, and has always been. If we end up with one executor in two years, we failed on that goal.
1 reply 0 retweets 2 likes -
Replying to @stjepang
I’m not sure why thousands of runtimes is something to aspire to.
2 replies 0 retweets 0 likes -
Replying to @mitsuhiko
Servers, browsers, mobile apps, and embedded devices need or already use different kinds of runtimes. Think about game engines, high frequency trading, routers, databases, custom runtimes (bastion, actix, deno, firecracker), etc. Many straight up refuse to use existing runtimes.
2 replies 0 retweets 3 likes
Go doesn't need to worry as much because it's primarily designed for servers, so it can have one runtime. But people want to use Rust everywhere. Environments on which async-std and tokio can compile and run well, and ones at which Rust excels are just a small part of that.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.