3 ms·

> Option and Result are Monads. Surely he misses do-notation. Rust does not have higher kinded types, which are required to have abstractions like the Functor

> Option and Result are Monads. Surely he misses do-notation. Rust does not have higher kinded types, which are required to have abstractions like the Functor and Monad type classes in Haskell. Option and Result are monadic, but they must implement their own, separate methods and can not share a common interface. Which takes away a lot of expressive power. There is a accepted proposal for something similar, known as GAT [1] (generic associated types). But that is blocked on other work and might never actually be implemented. [1] https://github.com/rust-lang/rust/issues/44265 https://github.com/rust-lang/rust/issues/44265

steveklabnik 6y ago
> But that is blocked on other work and might never actually be implemented. In a theoretical sense, sure, but in a practical sense, my understanding is that GATs already exist in chalk, and so it's still a matter of putting in the work, not a question of "is this possible or not."
- the_duke 6y ago
  I didn't mean to imply that it was impossible. You would know better of course, but it was my impression that there is no firm commitment to stabilizing GAT, even once the compiler fully switches to Chalk, due the potential disruptiveness and complication of the language. (For those unaware: Chalk is a rewrite of the trait logic in rustc, based on logic programming [1] ) [1] https://github.com/rust-lang/chalk https://github.com/rust-lang/chalk
  - steveklabnik 6y ago
    Gotcha; I had not heard that. Given the strong need for things like async trait methods, I would be surprised to hear that, but I also haven't been paying mega close attention.
    - the_duke 6y ago
      I couldn't provide a link where this was said either, and it would have been quite a while ago. I just remember reading about concerns in that direction. I think async trait methods could be stabilized without exposing GAT to the user. Of course I would very, very much like to have them either way, they would make certain abstractions much easier to build.
  - kibwen 6y ago
    > it was my impression that there is no firm commitment to stabilizing GAT Certainly, but not in the sense of being uncertain about whether or not GAT are worthwhile, only in the sense of not wanting to make promises that may not be able to be kept. The Rust developers want GAT--or something analogous to GAT--and much work has been put in towards that goal (work that will have been useful even without GAT), and at this juncture there's no foreseen theoretical impediments; however, that's not to say that some unforeseen impediment won't yet arise. Such a thing happened with specialization, which has been in the works for much longer (current status: https://github.com/rust-lang/rust/pull/68970 https://github.com/rust-lang/rust/pull/68970), and the lesson has been to not incite expectation until you are extremely certain the promise will be able to be kept. As a mere half-informed bystander it seems that GAT not encountering the problems that specialization did, but don't take this as any sort of promise. :)
    - the_duke 6y ago
      While I personally would really want both GAT (+ full HKT) and specialization, I could emphasize with some opposition to stabilizing them. Rust is already a complicated language. Those two features would increase the complexity of the type system quite significantly. Possibly beyond what is healthy for Rust adoption.
      - kibwen 6y ago
        The neat thing about GAT is that it doesn't really increase the user-facing complexity of the language. Conceptually, users already need to understand generics, and they need to understand associated types. GAT, which allows users to use generics within associated types, doesn't feel like a new feature so much as it just feels like letting two existing features play nicely.

steveklabnik 6y ago

> But that is blocked on other work and might never actually be implemented. In a theoretical sense, sure, but in a practical sense, my understanding is that GATs already exist in chalk, and so it's still a matter of putting in the work, not a question of "is this possible or not."

the_duke 6y ago
I didn't mean to imply that it was impossible. You would know better of course, but it was my impression that there is no firm commitment to stabilizing GAT, even once the compiler fully switches to Chalk, due the potential disruptiveness and complication of the language. (For those unaware: Chalk is a rewrite of the trait logic in rustc, based on logic programming [1] ) [1] https://github.com/rust-lang/chalk https://github.com/rust-lang/chalk
- steveklabnik 6y ago
  Gotcha; I had not heard that. Given the strong need for things like async trait methods, I would be surprised to hear that, but I also haven't been paying mega close attention.
  - the_duke 6y ago
    I couldn't provide a link where this was said either, and it would have been quite a while ago. I just remember reading about concerns in that direction. I think async trait methods could be stabilized without exposing GAT to the user. Of course I would very, very much like to have them either way, they would make certain abstractions much easier to build.
- kibwen 6y ago
  > it was my impression that there is no firm commitment to stabilizing GAT Certainly, but not in the sense of being uncertain about whether or not GAT are worthwhile, only in the sense of not wanting to make promises that may not be able to be kept. The Rust developers want GAT--or something analogous to GAT--and much work has been put in towards that goal (work that will have been useful even without GAT), and at this juncture there's no foreseen theoretical impediments; however, that's not to say that some unforeseen impediment won't yet arise. Such a thing happened with specialization, which has been in the works for much longer (current status: https://github.com/rust-lang/rust/pull/68970 https://github.com/rust-lang/rust/pull/68970), and the lesson has been to not incite expectation until you are extremely certain the promise will be able to be kept. As a mere half-informed bystander it seems that GAT not encountering the problems that specialization did, but don't take this as any sort of promise. :)
  - the_duke 6y ago
    While I personally would really want both GAT (+ full HKT) and specialization, I could emphasize with some opposition to stabilizing them. Rust is already a complicated language. Those two features would increase the complexity of the type system quite significantly. Possibly beyond what is healthy for Rust adoption.
    - kibwen 6y ago
      The neat thing about GAT is that it doesn't really increase the user-facing complexity of the language. Conceptually, users already need to understand generics, and they need to understand associated types. GAT, which allows users to use generics within associated types, doesn't feel like a new feature so much as it just feels like letting two existing features play nicely.