4 ms·

It's always possible there's a better way. If you know of one, maybe you can write a proposal? There is always Rust v2. Rust lacks a BDFL and so it's almost lik

It's always possible there's a better way. If you know of one, maybe you can write a proposal? There is always Rust v2. Rust lacks a BDFL and so it's almost like the language grows itself. Chances are, the async model that was used was picked because it was arrived upon via consensus.

lmm 6y ago
I don't think there is a better approach; I think the right thing would have been to lay proper functional foundations to make async practical. I did speak against NLL at the time, and I keep arguing that HKT should be a higher priority, but the consensus favoured the quick hack.
- ragnese 6y ago
  I agree that Rust should have embraced HKTs instead of resisting them every step of the way. It's been my observation that the Rust lang team is pretty much against HKTs as a general feature, which makes me sad. I'm also happy to meet the only other person who had reservations about NLL! :p I have mixed feelings about it, still. It really is super ergonomic and convenient, but I really value language simplicity and NLL makes the language more complex. I also don't think there's much Rust can do differently in regards to "functional foundations". With Rust's borrow/lifetime model, what would you even do differently with respect to `fn`, `Fn`, `FnMut`, and `FnOnce`?
  - steveklabnik 6y ago
    HKTs were considered, and do not actually solve the problem, in Rust. Rust is not Haskell. The differences matter. Nobody is against HKTs on some sort of conceptual level. They just literally do not work to solve this problem in Rust.
    - ragnese 6y ago
      Which problem are we referring to? I was only making a general statement that I think Rust would have benefited from HKTs instead of doing umpteen ad-hoc implementations of specific higher-kinded types. I'm far from an expert, so please correct me if I'm wrong: Wouldn't HKTs help us abstract over function/types more easily, including closures? Aren't GATs a special case of HKTs? If Rust somehow had HKTs and "real" monads, we could have a do-notation instead of the Try trait+operator and Future trait+async+await, right? I'm not saying that HKTs would fix (most of) the issues mentioned in the article around tricky closure semantics and whatnot.
      - steveklabnik 6y ago
        > Wouldn't HKTs help us abstract over function/types more easily, including closures? In the sense that HKTs are a higher level abstraction, sure. More later. > Aren't GATs a special case of HKTs? My understanding is that GATs can get similar things done to HKTs for some stuff that Rust cares about, but that doesn't give them a subtyping relationship. Haskell has both higher kinded types and type families. That being said, my copy of Pierce is gathering dust. > If Rust somehow had HKTs and "real" monads, we could have a do-notation instead of the Try trait+operator and Future trait+async+await, right? It depends on what you mean by "somehow." That is, even if Rust had a monad trait, that does not mean that Try and Future could both implement it. This is because, in Haskell, these things have the same signatures. In Rust, they do not have the same signature. For reference: pub trait Iterator { type Item; pub fn next(&mut self) -> Option<Self::Item>; } pub trait Future { type Output; pub fn poll( self: Pin<&mut Self>, cx: &mut Context<'_> ) -> Poll<Self::Output>; } While they are both traits, both with something returning their associated type: 1. Iterator returns Option, while Future returns something like it. These do have the same shape in the end though, so maybe this is surmountable. (Though then you have backwards compat issues) 2. poll takes a Pin'd mutable reference to self, whereas iterator does not 3. Future takes an extra argument These are real, practical problems that would need to be sorted, and it's not clear how, or even if it's possible to, sort them. Yes, if you handwave "they're sort of the same thing at a high enough level of abstraction!", sure, in theory, this could be done. But it is very unclear how, or if it is even possible to, get there.

lmm 6y ago

I don't think there is a better approach; I think the right thing would have been to lay proper functional foundations to make async practical. I did speak against NLL at the time, and I keep arguing that HKT should be a higher priority, but the consensus favoured the quick hack.

ragnese 6y ago
I agree that Rust should have embraced HKTs instead of resisting them every step of the way. It's been my observation that the Rust lang team is pretty much against HKTs as a general feature, which makes me sad. I'm also happy to meet the only other person who had reservations about NLL! :p I have mixed feelings about it, still. It really is super ergonomic and convenient, but I really value language simplicity and NLL makes the language more complex. I also don't think there's much Rust can do differently in regards to "functional foundations". With Rust's borrow/lifetime model, what would you even do differently with respect to `fn`, `Fn`, `FnMut`, and `FnOnce`?
- steveklabnik 6y ago
  HKTs were considered, and do not actually solve the problem, in Rust. Rust is not Haskell. The differences matter. Nobody is against HKTs on some sort of conceptual level. They just literally do not work to solve this problem in Rust.
  - ragnese 6y ago
    Which problem are we referring to? I was only making a general statement that I think Rust would have benefited from HKTs instead of doing umpteen ad-hoc implementations of specific higher-kinded types. I'm far from an expert, so please correct me if I'm wrong: Wouldn't HKTs help us abstract over function/types more easily, including closures? Aren't GATs a special case of HKTs? If Rust somehow had HKTs and "real" monads, we could have a do-notation instead of the Try trait+operator and Future trait+async+await, right? I'm not saying that HKTs would fix (most of) the issues mentioned in the article around tricky closure semantics and whatnot.
    - steveklabnik 6y ago
      > Wouldn't HKTs help us abstract over function/types more easily, including closures? In the sense that HKTs are a higher level abstraction, sure. More later. > Aren't GATs a special case of HKTs? My understanding is that GATs can get similar things done to HKTs for some stuff that Rust cares about, but that doesn't give them a subtyping relationship. Haskell has both higher kinded types and type families. That being said, my copy of Pierce is gathering dust. > If Rust somehow had HKTs and "real" monads, we could have a do-notation instead of the Try trait+operator and Future trait+async+await, right? It depends on what you mean by "somehow." That is, even if Rust had a monad trait, that does not mean that Try and Future could both implement it. This is because, in Haskell, these things have the same signatures. In Rust, they do not have the same signature. For reference: pub trait Iterator { type Item; pub fn next(&mut self) -> Option<Self::Item>; } pub trait Future { type Output; pub fn poll( self: Pin<&mut Self>, cx: &mut Context<'_> ) -> Poll<Self::Output>; } While they are both traits, both with something returning their associated type: 1. Iterator returns Option, while Future returns something like it. These do have the same shape in the end though, so maybe this is surmountable. (Though then you have backwards compat issues) 2. poll takes a Pin'd mutable reference to self, whereas iterator does not 3. Future takes an extra argument These are real, practical problems that would need to be sorted, and it's not clear how, or even if it's possible to, sort them. Yes, if you handwave "they're sort of the same thing at a high enough level of abstraction!", sure, in theory, this could be done. But it is very unclear how, or if it is even possible to, get there.