TBH I think that, for the most part, I will only benefit from a few of these - mostly in terms of sugar. I routinely have positive experiences with Async rust and basically never have negative experiences/ issues that crop up because of it. In 3 years of writing Rust full time I had one async problem one time - I accidentally was causing an infinite select! loop in a tonic server, so the server would hang. Not really a big deal for 3 years of async work. I could have done the same thing in sync code just as easily tbh.

I also don’t think that async-drop as quite as necessary or desirable as it may seem. I really wanted it at one point and then I realized that it’s just too tricky. It reminds me of how File calls sync_all on drop but ignores the error - ultimately, “drop” is just a really tricky place for anything complex. I’d rather see a linear type, like:

    struct LinearFile {
        fn close(self) -> Result<File, std::io::Error> { self.sync_all(); File { inner: self.inner } }
    }

Where Linear can’t be implicitly drop’d, you have to .close() it, get a File, and File can be dropped. Hand wavy and not necessarily a good implementation but hopefully this is getting the point across. This would be preferable to shoving more into a drop impl when drop is such a constrained interface.

Or maybe add a try_drop(&mut self) that will run implicity but also ? implicity. I don’t know.

I guess the point is that I’m not sure an async drop can ever be worth it.

TBH I feel like ~30% of people's complaints about async are solved by:

a) Encouraging a sync + async API in libraries

b) Adding `block_on` to the stdlib, which will help with (a)

People mostly seem to care (and imo this is stupid but whatever) about using async in sync contexts when they don't want to, and they don't seem to know that you can just block.