3 ms·

Maybe the limitations and logic around this ITRPiT (?) stuff make tons of sense to anyone who’s used to the Rust async typestack, but to an outsider this is alm

Maybe the limitations and logic around this ITRPiT (?) stuff make tons of sense to anyone who’s used to the Rust async typestack, but to an outsider this is almost completely incomprehensible gibberish, even after reading the fairly detailed blog posts about it. I like the idea of Rust, like many people do, but when I actually see convoluted language features like these it makes me think this is not a serious language meant to empower everyday users like it says on the label. I think at this point I’d almost rather use OCaml or Haskell.

satvikpendem 3y ago
Well, if you don't use the language, of course a more advanced feature would be gibberish. You'd have to actually learn the language from the beginning, not at the middle or end which is basically what this blog post is talking about. All that the blog post is saying is that if you have a trait A, you can make a function where it will return something that implements A, from another trait B. It's a way to make traits depend on another. It's similar to if you have an interface called Drivable (and classes that implement it, like Car or Bike) then you can make a function like `drive` that returns something that implements Drivable, inside some other trait. All that `async fn` is is syntactic sugar for something that implements the Future trait.
- 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 ago
    I 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.

satvikpendem 3y ago

Well, if you don't use the language, of course a more advanced feature would be gibberish. You'd have to actually learn the language from the beginning, not at the middle or end which is basically what this blog post is talking about. All that the blog post is saying is that if you have a trait A, you can make a function where it will return something that implements A, from another trait B. It's a way to make traits depend on another. It's similar to if you have an interface called Drivable (and classes that implement it, like Car or Bike) then you can make a function like `drive` that returns something that implements Drivable, inside some other trait. All that `async fn` is is syntactic sugar for something that implements the Future trait.

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 ago
  I 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.