Rust friends. Lets talk about async-std and tokio. There is a (relatively) polite cold war happening, and I'm pretty sure it's bad for all of us. Tokio paved a ridiculous amount of ground in the rust/async ecosystem, and it's been on a steady climb of improvement.
Much of that has been driven by real-world usage, building high performance networking code. That means it exposes all the knobs and fiddly bits you need when you care about the details. It also means that, when you first start, the experience is sometimes overwhelming.
It is, however, pretty damn solid. It's also quite quick, and pays a lot of attention to the details of what happens when you're in production (things like tail latency, which matters a lot when your request gets the shitty tail, and not so much when it doesn't.)
Tokio feels very rusty to me. It exposes the cost of your decisions, lets you tweak where you need to. It's clearly good software.
Async-Std has a slightly different target, I suspect. It looks at the problem from the angle of "what will be easiest for the user" - which is not a bad angle. But making it easy like that means making trade-offs about the costs - there is no free UX lunch.
You'll have fewer knobs, fewer fiddly bits. Things like the "magic" blocking support - which sounds good, but in reality is likely to bite in weird ways if you put it under high stress (we see this in other ecosystems too - go and .net spring to mind)
Ultimately, these are two very different perspectives on what the experience of building async software on rust should be like. Right now, though, we are at risk of having the complex primitives they should share (so that you can have the ecosystem ride on top) splinter.
As a veteran of more than a few open source cold wars myself: resist the urge to have a war. It's expensive, it's bad for your users, and it hurts your hearts. Listen to each others expertise - both academic and real-world. Figure it out. There is plenty of niche for both.
In order for the consumers to win, neither Tokio nor Async-Std has to win. What they do have to do is agree on what the basic primitives are - and to do that, they're going to need to put aside the idea that one or the other should "win".
