2 ms·
It’s not returning impl trait that is confusing, but the limitations surrounding it. Why shouldn’t there be send by default, why is send so important to the di
by binary132 3y ago
It’s not returning impl trait that is confusing, but the limitations surrounding it. Why shouldn’t there be send by default, why is send so important to the discussion? Why do we need to worry about GATs in this context? Why shouldn’t we expose this to users of our traits yet?
Why isn’t async straightforward? It seems like a fairly fundamental aspect of a language and a key differentiator. I suppose it has something to do with capturing a reference to self, but I don’t think I understood that bit either. And why are static impl traits supported but not dynamic?
At the end of the day this feature is simply inaccessible. I’m not a complete outsider, I understand why it’s useful to return a future of result user record, or the difference between impl trait and dyn trait.
There are fairly technical answers to these questions, and people have attempted to offer them, but I suppose I would need a master class to get me to where I could understand the answers.
That isn’t the case for async in most languages and I’m not really clear why people didn’t put a bit more care into the async API for Rust.
If your language requires an expert to use a fundamental feature, I feel there is a gap in the design principles.
- satvikpendem 3y agoI see, thought you didn't have experience with Rust, my mistake. To be honest I think most people are using Rust async just fine, with the async_trait crate, and Rust in general simply because most aren't doing anything too advanced or use workarounds where needed, via crates, syntactic desugaring, or otherwise. For example, I use Rust primarily for my backend web server via Axum, and I haven't really felt a need to stress too much about async, everything I need to work just works. Every language has its faults, people simply work around them to Get Shit Done.