3 ms·

Apples & Oranges. Although Rust heavily borrows from the ML family, the fact it has mutability and imperative reasoning makes it hard to compare them. But if

Apples & Oranges. Although Rust heavily borrows from the ML family, the fact it has mutability and imperative reasoning makes it hard to compare them. But if you want a short one: - Sum Types EDIT: AND Product Types (silly me) - function-objects & closures - typeclasses (as far as I can tell), but no higher kinded types - no monads, functors nor monoids built-in - trait objects (eg. runtime polymorphism, think "abstract classes")

ketralnis 9y ago
> - Sum Types but no Product Types Maybe I'm missing something, but aren't tuples and structs/records examples of product types? Which both rust and haskell have?
- mathw 9y ago
  Yes I always thought tuples were the archetypal product type, which is why in some ML dialects they're notated as "Type1 * Type2". Rust most certainly has them, as does Haskell. Records/structs of course are just the same thing with names for the components. Thus, even Java has product types.
  - masklinn 9y ago
    > Thus, even Java has product types. Even C has product types. Which is why I'm always bothered when people claim language X lacks algebraic data types. They probably lack sum types, but are very unlikely to lack product types.
    - beojan 9y ago
      C also has sum types with unions (though without any indication of which of the alternatives is actually present).
      - red75prime 9y ago
        They are mix types then.
    - kod 9y ago
      Product types without sum types and pattern matching are basically useless for expressing ADTs. That's what people mean.
      - masklinn 9y ago
        > Product types without sum types and pattern matching are basically useless for expressing ADTs. That makes no sense. Algebraic data types are not expressed, they're a concrete thing, a classification of composite types (by multiplication (hence product types) or addition (hence sum types)).
        kod 9y ago
        Sure it does, languages allow you to express things. Some shitty languages don't have a concise way for you to express particular things (like sum types), so you have to rely on idioms or "patterns".
  - kornish 9y ago
    Oh wow, never realized the connection between product types and the ML type notation. Thanks for the insight!
  - jmcomets 9y ago
    Thanks for the insight on this, I've edited my response. Are there any extra features in Haskell with product types? I've always understood that there was better composition support for product types in Haskell
    - bjz_ 9y ago
      Not really. Haskell has support for higher kinded types that allow it to support lenses, which are a powerful way of declaratively traversing through data structures, so perhaps that's what you mean. On the other hand Haskell's record support is pretty woeful in comparison to languages like Ocaml, Elm, and Purescript that have support for row polymorphism. Depending on the sophistication of their implementation, row polymorphism will allow you to add and remove fields from records in a statically type checked way, and some may even allow you to pass labels around at the type level. They can even be used to model extensible variants and extensible effect types. There are creative ways to encode this in Haskell, but they all have their drawbacks, can be painful to work with, and really don't feel like a natural part of the language.
    - kazagistar 9y ago
      Well, there is per-field lazyness (with the ability to opt out). So product types can let each consumer choose which parts of the result to actually evaluate and discard the rest.
  - bjz_ 9y ago
    And in SML tuples are just records with numeric fields in a special order. Enter this in the repl: { 1 = "hi", 2 = "howdy" }; And get: val it = ("hi","howdy") : string * string
MHordecki 9y ago
There are other imperative languages in the ML family too, right? OCaml has an imperative mode. I don't think Rust is that much different from other functional languages. The main critical difference is the manual memory management feature - the way it's acknowledged and used throughout the language and the ecosystem means that the functional patterns commonly used in garbage collected languages don't look nearly as natural in Rust.

ketralnis 9y ago

> - Sum Types but no Product Types Maybe I'm missing something, but aren't tuples and structs/records examples of product types? Which both rust and haskell have?

mathw 9y ago
Yes I always thought tuples were the archetypal product type, which is why in some ML dialects they're notated as "Type1 * Type2". Rust most certainly has them, as does Haskell. Records/structs of course are just the same thing with names for the components. Thus, even Java has product types.
- masklinn 9y ago
  > Thus, even Java has product types. Even C has product types. Which is why I'm always bothered when people claim language X lacks algebraic data types. They probably lack sum types, but are very unlikely to lack product types.
  - beojan 9y ago
    C also has sum types with unions (though without any indication of which of the alternatives is actually present).
    - red75prime 9y ago
      They are mix types then.
  - kod 9y ago
    Product types without sum types and pattern matching are basically useless for expressing ADTs. That's what people mean.
    - masklinn 9y ago
      > Product types without sum types and pattern matching are basically useless for expressing ADTs. That makes no sense. Algebraic data types are not expressed, they're a concrete thing, a classification of composite types (by multiplication (hence product types) or addition (hence sum types)).
      - kod 9y ago
        Sure it does, languages allow you to express things. Some shitty languages don't have a concise way for you to express particular things (like sum types), so you have to rely on idioms or "patterns".
- kornish 9y ago
  Oh wow, never realized the connection between product types and the ML type notation. Thanks for the insight!
- jmcomets 9y ago
  Thanks for the insight on this, I've edited my response. Are there any extra features in Haskell with product types? I've always understood that there was better composition support for product types in Haskell
  - bjz_ 9y ago
    Not really. Haskell has support for higher kinded types that allow it to support lenses, which are a powerful way of declaratively traversing through data structures, so perhaps that's what you mean. On the other hand Haskell's record support is pretty woeful in comparison to languages like Ocaml, Elm, and Purescript that have support for row polymorphism. Depending on the sophistication of their implementation, row polymorphism will allow you to add and remove fields from records in a statically type checked way, and some may even allow you to pass labels around at the type level. They can even be used to model extensible variants and extensible effect types. There are creative ways to encode this in Haskell, but they all have their drawbacks, can be painful to work with, and really don't feel like a natural part of the language.
  - kazagistar 9y ago
    Well, there is per-field lazyness (with the ability to opt out). So product types can let each consumer choose which parts of the result to actually evaluate and discard the rest.
- bjz_ 9y ago
  And in SML tuples are just records with numeric fields in a special order. Enter this in the repl: { 1 = "hi", 2 = "howdy" }; And get: val it = ("hi","howdy") : string * string

MHordecki 9y ago

There are other imperative languages in the ML family too, right? OCaml has an imperative mode. I don't think Rust is that much different from other functional languages. The main critical difference is the manual memory management feature - the way it's acknowledged and used throughout the language and the ecosystem means that the functional patterns commonly used in garbage collected languages don't look nearly as natural in Rust.