Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> What’s wrong with async_std?

The problem is that it exists. Or rather, that multiple async libraries exist and every attempt to employ asynchronous programming in Rust inevitably leaves you with the problem of aligning these different, redundant, incompatible, incomplete, evolving async libraries, which is an unmitigated disaster.

Rust, all by itself, is a non-trivial hill climb for developers. They're willing to bust out the climbing tools and make the attempt because they see the value. But then they get hit in the head by debris like futures::io::AsyncRead <-> tokio::io::AsyncRead and that is it; they come down off the hill and go find something else to scale. Worse yet they don't talk about it; they love Rust, the idea of Rust, and they want it to thrive so they avoid being critical.

IO and async is fundamental. It's too fundamental to suffer multiple, partial, incompatible, ever evolving realizations. This is the number one issue that threatens Rust. People have only so much patience to spare; only so many attempts they're will to make climbing the same hill.

I have hope. Companies like Amazon and Microsoft are making serious commitments to Rust because they too see the value. They're going to get knocked in the head by the same falling debris. And so there is a chance that while this is all still young and the MBAs and lawyers and rent seekers aren't yet savvy, Rust will receive the sort of tedious, expensive labor it so desperately needs to mature.



This is why I like async_std. It’s literally the same types as the normal standard lib but it returns futures for anything that could block. If you know the normal standard lib then you know async_std. I’ve stayed the hell away from Tokio for the reasons you’re expressing, but async_std seems like a solution to the problem, not a cause.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: