> 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;
}
pub trait Future {
type Output;
pub fn poll(
self: Pin,
cx: &mut Context
) -> Poll;
}
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.