11 ms·

> It manages to be much faster than most dynamic languages ... It would be unfair to compare the performance of Rust and Haskell, because Haskell is optimized

> It manages to be much faster than most dynamic languages ... It would be unfair to compare the performance of Rust and Haskell, because Haskell is optimized for things other than performance. Hmm... > When I first started using Rust, I really missed monads. Option and Result are Monads. Surely he misses do-notation. > This all being said, I think it is worth looking at the features that are prominent in Haskell that ended up going to Rust ...[list of features that Rust got from SML/ocaml] Here are the officially stated Rust influences: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html To say that Rust is a child of Haskell is really overstating the case.

eru 6y ago
> Option and Result are Monads. Surely he misses do-notation. Well, functions and lists are also monads. I guess what the author means is that the language recognises the similarity of those disparate structures.
dimitrios1 6y ago
IIRC Rust was influenced more by OCaml than Haskell, but I could be wrong. The article really rubbed me the wrong way with this tidbit > (we don’t talk about Go…) So since the author is speaking of "premier system’s language" we choose to ignore the world's premier cloud language? Interesting.
- zingplex 6y ago
  I'm pretty sure that was just a joke about Go's primitive type system.
  - dimitrios1 6y ago
    I mean if we save the "intellectual superiority" of Haskells or other FP languages -- (I've used them all) -- in practice with teams of other engineers, and in production where it counts the most, Go has outshined them all. So primitive is surely a way to describe it.
    - kdkeyser 6y ago
      I fail to see how else than "primitive" you can call the Go type system: it is roughly what you would get from a language designed in the 70's, and a lot of advances have since been made. Whether or not these advances make a difference (positive or negative) in production is different question, but I'd rather not use "how much is a language used", as an inherent quality metric for a programming language. Otherwise, I fear we might all end up doing old-school Java, Javascript, Visual Basic and ABAP.
      - dimitrios1 6y ago
        > "how much is a language used", as an inherent quality metric for a programming language. Define quality. Because what I've realized with the PL-elitist crowd is this almost always boils down to "the ability to be expressive" which is fine but it certainly isn't a complete metric, and, to borrow a common refrain, we've had expressive languages in the 70's as well, we've had s-expressions for a while now. What about other metrics, such as "ability for mass amounts of programmers to program the computer to do the correct thing?" and "ability for programmer to maintain said program?" -- you know, real world quality. My point is, people's usual quality metrics are often incomplete or narrowly defined. In either case, if Go is so primitive, then why didn't the 70s produce a language like Go? Why did developers who created languages, operating systems, and systems software in the 70s not make Go until the 2000s (you do know who created Go, right?) I just don't buy this argument, especially having used those "advanced" type systems for many years, sorry.
        AnimalMuppet 6y ago
        I mostly agree with you, but the claim was that Go's type system was 70s-era primitive. And I think that claim is probably correct. The type system of Go isn't all that sophisticated or "advanced". But all that says is that the magic of Go isn't in the type system. The couldn't produce-it-until-the-2000s isn't in the type system. The thing that makes Go more used in the real world than Haskell isn't the sophistication of the type system. I don't see much to argue with in those claims.
        6y ago
- JulianMorrison 6y ago
  I was amused at that. It's clear this author is not Go's constituency. You cannot use types to ensure consistency in Go, you just have to write the algorithm correctly. But Go fronts the algorithm and keeps the noise around it to a minimum. They are opposed but equivalent strategies.
  - eru 6y ago
    You still have to get the algorithms right in eg Haskell. It's just that in Haskell you have to write fewer tests to be sure you did it right, because for many kinds of mistakes you could have made, the compiler can yell at you. The other advantage of nicer types is that they serve as part of the documentation. Exactly because the types can constraint the behaviour of implementations more than in Go. So the reader can make more valid assumptions from the type alone. Hoogle uses those types to give you a truly extra-ordinary way to search the Haskell libraries via types. That approach would be almost useless in Go, and you have to fall back to searching via keywords etc only.
- steveklabnik 6y ago
  Rust was initially implemented in OCaml, even. But that said, it gained a lot of more Haskell like features later on; we ended up with type classes, not ML modules, for example. EDIT: also, strictly speaking, Rust doesn't use Hindley-Milner, and we don't have parametric polymorphism.
  - veets 6y ago
    Can you clarify why you don't think Rust has parametric polymorphism? struct Person<T> { age: T, } Is parametric polymorphism and valid Rust.
    - steveklabnik 6y ago
      Just because some bounds are parametric does not mean that all of them are; specialization violates parametricity, for example. While that's not in Rust proper yet, it did require making sure that dropck could handle it, for example, and the intention is to ship it. There's also more minor things like https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179973108 https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179...
      - Rusky 6y ago
        In a sense even things like `TypeId::of` or `mem::size_of` violate parametricity.
      - veets 6y ago
        I don't doubt you know more about Rust than I do, but this seems pedantic to me. Kind of like correcting someone for pronouncing forte as "for-TAY" instead of "fort" or telling someone "well technically you don't actually touch _anything_ because of the electrostatic force." If you ask all the developers out there to describe parametric and ad-hoc polymorphism I think a vast majority would give the example of a type parameter (e.g., Java generics or C++ templates) for parametric polymorphism and Java interfaces or Haskell's classes for ad-hoc polymorphism. I can even quote directly from Pierce (Types and Programming Languages): > Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed "generically," using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same. I think Rust and the aforementioned languages fit this definition. Outside of a specific compiler issue, claiming otherwise seems to only confuse the issue, especially for those just casually reading and not familiar with programming language theory.
- cgh 6y ago
  Yes, this was my favourite line: > However, in 2020, the premier system’s language is surely Rust. Yesterday I was speaking with a friend who runs a small company doing contracted embedded programming (the embedded OS is often Linux but often not) and he'd never even heard of Rust. Maybe it's a little lower level than what's meant by "systems" here but still, the article's statement is just delusional.
  - Jtsummers 6y ago
    The largest vocal community today for a systems language (meaning down to the OS level with strong determinism guarantees, not the redefinition to make Go a systems language meaning server systems) is definitely Rust. But in practice, no one is using it because their systems predate it, don't have compilers for it, or they simply can't use it due to their problem domain (it has an insufficient history, they can't contract support with the compiler team for it, or whatever). I can go to Green Hills and get a contract that guarantees their compiler will be available and supported for my target platform for the next 10+ years. Rust is still a moving target with a single implementation, and no (present) way to get the guarantees needed for the embedded domains I've been involved in. I'd like to see Rust experimented with there, but it won't be the "go to" language for quite some time.
    - steveklabnik 6y ago
      Fun story: here's a recent talk by someone at Green Hills, talking about experiences giving Rust a try https://www.youtube.com/watch?v=G5A7rSPYpb8 https://www.youtube.com/watch?v=G5A7rSPYpb8
      - Jtsummers 6y ago
        Thanks for the link, I'll check it out later.
      - deleted 6y ago
        [deleted]
    - dimitrios1 6y ago
- rowanG077 6y ago
  How is Go the premier cloud computing language? I would say that crown goes to Python. I almost never encounter Go when working with cloud computing.
- sweeneyrod 6y ago
  What does "premier cloud language" mean?
- eru 6y ago
  Are you saying Go is the 'premier system's language'?
creata 6y ago
> Option and Result are Monads. Surely he misses do-notation. You can find monads everywhere if you look hard enough. But Haskell actually lets you use those discoveries for massive code reuse, while Rust forces you to write stuff like Result::and_then and Result::map over and over again. > To say that Rust is a child of Haskell is really overstating the case. Right, most of these are common influences. I'd say Rust's main contributions are (a) the ownership system, and (b) painting a thin coat of C++ syntax over ML features to make them more palatable, and neither of these seem all that inspired by Haskell.
- fnord123 6y ago
  >Rust forces you to write stuff like Result::and_then and Result::map over and over again. The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.
  - 59nadir 6y ago
    What everyone is talking about isn't "not having to write `and_then` over and over" but rather that there is a common interface to "things that are monads", i.e. `>>=`, `map` and `apply`. `do`-notation is nice syntactic sugar on top of that common interface, but it's not the actual thing itself.
  - choeger 6y ago
    It is not. do notation is just syntactic sugar. The feature that enables re-use are the type-classes and the structure of the standard library. Interestingly, you do have traits in rust, but I think there is no monad trait yet in the std lib.
    - steveklabnik 6y ago
      There is not a monad trait because we do not have higher kinded types, which is a requirement. Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.
homami 6y ago
Haskell's killer feature here is higher kinded types. do notation is just a syntactic sugar. But (with the exception of Scala or PureScript) almost no other every-day language supports the ability for defining abstractions over higher kinded constructs like monads.
- bad_user 6y ago
  I'm primarily a Scala developer, that also likes Haskell. And you're right. With the caveat that some languages support an encoding of HKTs. You can encode HKTs in OCaml, Kotlin, or TypeScript for example, and there are FP libraries taking advantage of that. I believe the encoding was inspired by this paper: https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-kinded-polymorphism.pdf https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki... It kind of sucks, but it does let you work with a Monad type class, and it's better than not doing it at all. I'm not sure if such an encoding is possible in Rust. I've been told that F# has a hard time with it, not sure why (possibly because of reified generics). In TypeScript and Kotlin it works because the runtime and the type systems are relaxed and you can just force downcasts if you're in trouble.
  - Twisol 6y ago
    > I believe the encoding was inspired by this paper Just to add some tangential color here: even if you don't intend to use this encoding in production, it can be a fruitful intermediate step in refactoring! I just recently ran into a situation in Java where I had some tightly-coupled concerns for which HKTs were the obvious way out. Since Java doesn't have HKTs, I applied the HKT encoding to get the hard part out of the way, and then discovered a simplification that brought me back into the realm of idiomatic Java. I would not have found the final solution had I not pathed through HKTs -- I actually thought it would be impossible to do this decoupling properly at first! More color: the paper itself describes this approach as an application of defunctionalization. I use defunctionalization a lot, too, to write an obvious recursive solution and then mechanically transform it into an iterative one. So it's nice to know how to apply it at the type level, too ;)
eklavya 6y ago
>> When I first started using Rust, I really missed monads. > Option and Result are Monads. Surely he misses do-notation. Surely you are joking if you are trying to say someone writing haskell would say rust has monads in any practical sense. Sure, all languages have/can have A (or two) monad.
the_duke 6y ago
> 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.
josephcsible 6y ago
> Option and Result are Monads. Surely he misses do-notation. That's part of it. Option and Result are concrete instances of Monads. He misses the Monad abstraction.
ianhorn 6y ago
To add to what everyone else is saying, higher kinded types (HKTs) are what make monadic code really reusable. It lets you write code that is polymorphic over a variable kind of monad, rather than code that works for a specific monad like a list. Without HKTs, you might have a polymorphic type signature List[<T>] of a list of some variable kind of elements, or a Set[<T>], or a Maybe[<T>]. In haskell syntax it's List a, Set a, Maybe a. When you write code that operates on something like a monad, without caring about what the monad is, you want code that has a type like <T1>[<T2>]. In haskell syntax, it's m a. <T1> (or m) in this case is a type that takes another type as an argument to complete a concrete type. AFAIK, rust doesn't have type variables that take type variables (or types) as arguments like that.
Reisande 6y ago
https://docs.rs/functional/0.0.5/functional/trait.Monad.html https://docs.rs/functional/0.0.5/functional/trait.Monad.html

eru 6y ago

> Option and Result are Monads. Surely he misses do-notation. Well, functions and lists are also monads. I guess what the author means is that the language recognises the similarity of those disparate structures.

dimitrios1 6y ago

IIRC Rust was influenced more by OCaml than Haskell, but I could be wrong. The article really rubbed me the wrong way with this tidbit > (we don’t talk about Go…) So since the author is speaking of "premier system’s language" we choose to ignore the world's premier cloud language? Interesting.

zingplex 6y ago
I'm pretty sure that was just a joke about Go's primitive type system.
- dimitrios1 6y ago
  I mean if we save the "intellectual superiority" of Haskells or other FP languages -- (I've used them all) -- in practice with teams of other engineers, and in production where it counts the most, Go has outshined them all. So primitive is surely a way to describe it.
  - kdkeyser 6y ago
    I fail to see how else than "primitive" you can call the Go type system: it is roughly what you would get from a language designed in the 70's, and a lot of advances have since been made. Whether or not these advances make a difference (positive or negative) in production is different question, but I'd rather not use "how much is a language used", as an inherent quality metric for a programming language. Otherwise, I fear we might all end up doing old-school Java, Javascript, Visual Basic and ABAP.
    - dimitrios1 6y ago
      > "how much is a language used", as an inherent quality metric for a programming language. Define quality. Because what I've realized with the PL-elitist crowd is this almost always boils down to "the ability to be expressive" which is fine but it certainly isn't a complete metric, and, to borrow a common refrain, we've had expressive languages in the 70's as well, we've had s-expressions for a while now. What about other metrics, such as "ability for mass amounts of programmers to program the computer to do the correct thing?" and "ability for programmer to maintain said program?" -- you know, real world quality. My point is, people's usual quality metrics are often incomplete or narrowly defined. In either case, if Go is so primitive, then why didn't the 70s produce a language like Go? Why did developers who created languages, operating systems, and systems software in the 70s not make Go until the 2000s (you do know who created Go, right?) I just don't buy this argument, especially having used those "advanced" type systems for many years, sorry.
      - AnimalMuppet 6y ago
        I mostly agree with you, but the claim was that Go's type system was 70s-era primitive. And I think that claim is probably correct. The type system of Go isn't all that sophisticated or "advanced". But all that says is that the magic of Go isn't in the type system. The couldn't produce-it-until-the-2000s isn't in the type system. The thing that makes Go more used in the real world than Haskell isn't the sophistication of the type system. I don't see much to argue with in those claims.
      - 6y ago
JulianMorrison 6y ago
I was amused at that. It's clear this author is not Go's constituency. You cannot use types to ensure consistency in Go, you just have to write the algorithm correctly. But Go fronts the algorithm and keeps the noise around it to a minimum. They are opposed but equivalent strategies.
- eru 6y ago
  You still have to get the algorithms right in eg Haskell. It's just that in Haskell you have to write fewer tests to be sure you did it right, because for many kinds of mistakes you could have made, the compiler can yell at you. The other advantage of nicer types is that they serve as part of the documentation. Exactly because the types can constraint the behaviour of implementations more than in Go. So the reader can make more valid assumptions from the type alone. Hoogle uses those types to give you a truly extra-ordinary way to search the Haskell libraries via types. That approach would be almost useless in Go, and you have to fall back to searching via keywords etc only.
steveklabnik 6y ago
Rust was initially implemented in OCaml, even. But that said, it gained a lot of more Haskell like features later on; we ended up with type classes, not ML modules, for example. EDIT: also, strictly speaking, Rust doesn't use Hindley-Milner, and we don't have parametric polymorphism.
- veets 6y ago
  Can you clarify why you don't think Rust has parametric polymorphism? struct Person<T> { age: T, } Is parametric polymorphism and valid Rust.
  - steveklabnik 6y ago
    Just because some bounds are parametric does not mean that all of them are; specialization violates parametricity, for example. While that's not in Rust proper yet, it did require making sure that dropck could handle it, for example, and the intention is to ship it. There's also more minor things like https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179973108 https://github.com/rust-lang/rfcs/pull/1210#issuecomment-179...
    - Rusky 6y ago
      In a sense even things like `TypeId::of` or `mem::size_of` violate parametricity.
    - veets 6y ago
      I don't doubt you know more about Rust than I do, but this seems pedantic to me. Kind of like correcting someone for pronouncing forte as "for-TAY" instead of "fort" or telling someone "well technically you don't actually touch _anything_ because of the electrostatic force." If you ask all the developers out there to describe parametric and ad-hoc polymorphism I think a vast majority would give the example of a type parameter (e.g., Java generics or C++ templates) for parametric polymorphism and Java interfaces or Haskell's classes for ad-hoc polymorphism. I can even quote directly from Pierce (Types and Programming Languages): > Parametric polymorphism, the topic of this chapter, allows a single piece of code to be typed "generically," using variables in place of actual types, and then instantiated with particular types as needed. Parametric definitions are uniform: all of their instances behave the same. I think Rust and the aforementioned languages fit this definition. Outside of a specific compiler issue, claiming otherwise seems to only confuse the issue, especially for those just casually reading and not familiar with programming language theory.
cgh 6y ago
Yes, this was my favourite line: > However, in 2020, the premier system’s language is surely Rust. Yesterday I was speaking with a friend who runs a small company doing contracted embedded programming (the embedded OS is often Linux but often not) and he'd never even heard of Rust. Maybe it's a little lower level than what's meant by "systems" here but still, the article's statement is just delusional.
- Jtsummers 6y ago
  The largest vocal community today for a systems language (meaning down to the OS level with strong determinism guarantees, not the redefinition to make Go a systems language meaning server systems) is definitely Rust. But in practice, no one is using it because their systems predate it, don't have compilers for it, or they simply can't use it due to their problem domain (it has an insufficient history, they can't contract support with the compiler team for it, or whatever). I can go to Green Hills and get a contract that guarantees their compiler will be available and supported for my target platform for the next 10+ years. Rust is still a moving target with a single implementation, and no (present) way to get the guarantees needed for the embedded domains I've been involved in. I'd like to see Rust experimented with there, but it won't be the "go to" language for quite some time.
  - steveklabnik 6y ago
    Fun story: here's a recent talk by someone at Green Hills, talking about experiences giving Rust a try https://www.youtube.com/watch?v=G5A7rSPYpb8 https://www.youtube.com/watch?v=G5A7rSPYpb8
    - Jtsummers 6y ago
      Thanks for the link, I'll check it out later.
    - deleted 6y ago
      [deleted]
  - dimitrios1 6y ago
rowanG077 6y ago
How is Go the premier cloud computing language? I would say that crown goes to Python. I almost never encounter Go when working with cloud computing.
sweeneyrod 6y ago
What does "premier cloud language" mean?
eru 6y ago
Are you saying Go is the 'premier system's language'?

creata 6y ago

> Option and Result are Monads. Surely he misses do-notation. You can find monads everywhere if you look hard enough. But Haskell actually lets you use those discoveries for massive code reuse, while Rust forces you to write stuff like Result::and_then and Result::map over and over again. > To say that Rust is a child of Haskell is really overstating the case. Right, most of these are common influences. I'd say Rust's main contributions are (a) the ownership system, and (b) painting a thin coat of C++ syntax over ML features to make them more palatable, and neither of these seem all that inspired by Haskell.

fnord123 6y ago
>Rust forces you to write stuff like Result::and_then and Result::map over and over again. The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.
- 59nadir 6y ago
  What everyone is talking about isn't "not having to write `and_then` over and over" but rather that there is a common interface to "things that are monads", i.e. `>>=`, `map` and `apply`. `do`-notation is nice syntactic sugar on top of that common interface, but it's not the actual thing itself.
- choeger 6y ago
  It is not. do notation is just syntactic sugar. The feature that enables re-use are the type-classes and the structure of the standard library. Interestingly, you do have traits in rust, but I think there is no monad trait yet in the std lib.
  - steveklabnik 6y ago
    There is not a monad trait because we do not have higher kinded types, which is a requirement. Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.

homami 6y ago

Haskell's killer feature here is higher kinded types. do notation is just a syntactic sugar. But (with the exception of Scala or PureScript) almost no other every-day language supports the ability for defining abstractions over higher kinded constructs like monads.

bad_user 6y ago
I'm primarily a Scala developer, that also likes Haskell. And you're right. With the caveat that some languages support an encoding of HKTs. You can encode HKTs in OCaml, Kotlin, or TypeScript for example, and there are FP libraries taking advantage of that. I believe the encoding was inspired by this paper: https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-kinded-polymorphism.pdf https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki... It kind of sucks, but it does let you work with a Monad type class, and it's better than not doing it at all. I'm not sure if such an encoding is possible in Rust. I've been told that F# has a hard time with it, not sure why (possibly because of reified generics). In TypeScript and Kotlin it works because the runtime and the type systems are relaxed and you can just force downcasts if you're in trouble.
- Twisol 6y ago
  > I believe the encoding was inspired by this paper Just to add some tangential color here: even if you don't intend to use this encoding in production, it can be a fruitful intermediate step in refactoring! I just recently ran into a situation in Java where I had some tightly-coupled concerns for which HKTs were the obvious way out. Since Java doesn't have HKTs, I applied the HKT encoding to get the hard part out of the way, and then discovered a simplification that brought me back into the realm of idiomatic Java. I would not have found the final solution had I not pathed through HKTs -- I actually thought it would be impossible to do this decoupling properly at first! More color: the paper itself describes this approach as an application of defunctionalization. I use defunctionalization a lot, too, to write an obvious recursive solution and then mechanically transform it into an iterative one. So it's nice to know how to apply it at the type level, too ;)

eklavya 6y ago

>> When I first started using Rust, I really missed monads. > Option and Result are Monads. Surely he misses do-notation. Surely you are joking if you are trying to say someone writing haskell would say rust has monads in any practical sense. Sure, all languages have/can have A (or two) monad.

the_duke 6y ago

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

josephcsible 6y ago

> Option and Result are Monads. Surely he misses do-notation. That's part of it. Option and Result are concrete instances of Monads. He misses the Monad abstraction.

ianhorn 6y ago

To add to what everyone else is saying, higher kinded types (HKTs) are what make monadic code really reusable. It lets you write code that is polymorphic over a variable kind of monad, rather than code that works for a specific monad like a list. Without HKTs, you might have a polymorphic type signature List[<T>] of a list of some variable kind of elements, or a Set[<T>], or a Maybe[<T>]. In haskell syntax it's List a, Set a, Maybe a. When you write code that operates on something like a monad, without caring about what the monad is, you want code that has a type like <T1>[<T2>]. In haskell syntax, it's m a. <T1> (or m) in this case is a type that takes another type as an argument to complete a concrete type. AFAIK, rust doesn't have type variables that take type variables (or types) as arguments like that.

Reisande 6y ago

https://docs.rs/functional/0.0.5/functional/trait.Monad.html https://docs.rs/functional/0.0.5/functional/trait.Monad.html