3 ms·
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 a
by insanitybit 3y ago
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.
- mplanchard 3y agoI wish that some of these folks complaining about how rust libraries force you to use async would go out and write some equivalent libraries with synchronous APIs. Rust's philosophy has always been to let library authors explore a problem space before (if ever) pulling stuff into the stdlib, and I think it is generally only beneficial for the ecosystem to have multiple ways of solving a problem.
- insanitybit 3y agoI think it goes to show that the vast majority of Rust devs don't actually care about this problem, otherwise they'd be doing that already. Like, providing a sync API over an async API is almost always as simple as: struct SyncThing { async_version: AsyncThing } impl SyncThing { pub fn sync_api(&self) { block_on(self.async_version.sync_api) } } If this were really such a huge problem I think we'd see more PRs. I get that there's some survivorship bias here, but still...
- ReactiveJelly 3y agoIs that the same as the "Unforgetable types" mentioned in the blog? I never thought about it but, my only problem with C's manual destructors is that the compiler doesn't check that you remember to call them. If we accept a language like Rust that does sophisticated static analysis, it doesn't need to delete things for you, it only needs to be sure you have a plan to delete everything. That's interesting.
- insanitybit 3y ago> Is that the same as the "Unforgetable types" mentioned in the blog? Pretty much, yes. > I never thought about it but, my only problem with C's manual destructors is that the compiler doesn't check that you remember to call them. Right, so in this case the compiler would force you to consume the value somehow. This is "linear" typing.