3 ms·

Add to this: trait system vs deep OOP. Really nice macro system. First class serde. First class sync/send Derives!

pjmlp 2y ago
"Applying Traits to the Smalltalk Collection Classes", 2003 https://rmod-files.lille.inria.fr/Team/Texts/Papers/Blac03a-OOSPLA03-TraitsHierarchy.pdf https://rmod-files.lille.inria.fr/Team/Texts/Papers/Blac03a-... Traits as CS concept, are part of OOP paradigm.
- jvanderbot 2y ago
  There are shades of OOP, and while you're technically correct I think the meaning of my post is clear.
- sshine 2y ago
  Traits as CS concept, are part of FP paradigm. Reverse Uno!
  - pjmlp 2y ago
    Yes, and someone called Simon Peyton Jones happens to have a talk on how Haskell type classes and classical OOP interfaces interrelate.
    - sshine 2y ago
      Yes, and someone called Gabriella Gonzales happens to have a blog post on how objects are like comonads: https://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html https://www.haskellforall.com/2013/02/you-could-have-invente... And someone called Samuel the Bloggy Badger happens to have another blog posts on how comonads are really more like neighborhoods: https://gelisam.blogspot.com/2013/07/comonads-are-neighbourhoods-not-objects.html https://gelisam.blogspot.com/2013/07/comonads-are-neighbourh... ...so it might all just be a scam!
- kccqzy 2y ago
  The traits concept mentioned in your link looks very different from Rust traits. It describes something more akin to Java interfaces.
  - pjmlp 2y ago
    Java interfaces are based on Objective-C protocols. The only big difference is how implementation is mapped into the trait specification.
    - kccqzy 2y ago
      And that's the problem isn't it? Rust traits are based on GHC type classes, not at all from either Java or Objective-C or Smalltalk.
      - pjmlp 2y ago
        Thankfully this fellow Simon Peyton Jones has a talk about how they map into OOP paradigm. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://www.microsoft.com/en-us/research/publication/classes-jim-not-know-2009/ https://www.microsoft.com/en-us/research/publication/classes... "Adventure with Types in Haskell" https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=brE_dyedGm0 https://www.youtube.com/watch?v=brE_dyedGm0 On the first lecture he discusses how Haskell relates to OOP in regards of subtyping and generic polymorphism and how although different on the surface they share those CS concepts in their own ways.
        kccqzy 2y ago
        No. Did you read the contents of the links you shared? The name of the slides in your first link is "Classes, Jim, but not as we know them". And let me quote from the slides in your first link: From slide 40: > So the links to intensional polymorphism are closer than the links to OOP. From the first bullet of slide 43: > No problem with multiple constraints > f :: (Num a, Show a) => a -> ... From the second bullet: > Existing types can retroactively be made instances of new type classes (e.g. introduce new Wibble class, make existing types an instance of it): > class Wibble a where > wib :: a -> Bool > instance Wibble Int where > wib n = n+1 From slide 46: > In Haskell you must anticipate the need to act on arguments of various type > f :: Tree -> Int > vs > f’ :: Treelike a => a -> Int > (in OO you can retroactively sub-class Tree) From slide 50: > In Java (ish): > inc :: Numable -> Numable > from any sub-type of Numable to any super-type of Numable > In Haskell: > inc :: Num a => a -> a > Result has precisely same type as argument I appreciate you sharing informative links even though they prove you wrong. I haven't seen this set of slides before but I find it a very good concise explanation of why Haskell classes are not traditional OOP classes or interfaces.
- rmgk 2y ago
  Traits in Rust are more a variant of Haskell typeclasses than of Smalltalk traits. The whole FP vs OOP distinction does make little sense these days, as it has mostly been shown that each concept from the one can neatly fit within the other and vice versa.
Asraelite 2y ago
> First class serde. What do you mean? `Serialize` and `Deserialize` are not part of std.
- tialaramex 2y ago
  It's true, they're not part of the standard library. Nevertheless, it is conventional to provide implementations for things you reasonably expect your users might want to serialize and deserialize. Standard guidance includes telling you to name a feature flag (if you want one for this) serde and not something else so as to reduce extra work for your users. Because Rust's package ecosystem is more robust it's less anxious about the strict line between things everybody must have (in the standard library) and things most people want (maybe or maybe not in the standard library). In C++ there's a powerful urge to land everything you might need in the stdlib, so that it's available. For example the FreeBSD base system includes C++. They're not keen on adding to their base system, so for example they seem disinclined to take Rust, but when each C++ ISO standard bolts in whatever new random nonsense well that's part of C++ so it's in the base system for free. Weird data structure a game dev wants? An entire linear algebra system from Fortran? Comprehensive SI unit systems? It's not up to the FreeBSD gatekeepers, a WG21 vote gets all of those huge requirements into FreeBSD anyway.
  - jvanderbot 2y ago
    This was a conscious decision by Rust folks. Let the language and std libraries be small enough to target anything - and let well-established crates (most written/started by the rust folks) fill in functionality. The main language provided the baseline interfaces, in some cases (see async), but not the machinery (e.g., async runtimes).
  - loeg 2y ago
    FWIW C++ in FreeBSD is a little contentious. The overall system build time is dominated by Clang, with the rest of FreeBSD "a wart on the side." In base, the C++ compiler was pretty much only used for devd (something vaguely like Linux' udev), and devd is written in a pre-C++11 dialect -- no new features. Using more of it isn't exactly encouraged; it's not allowed in the kernel. There are two significant barriers to Rust in FreeBSD base -- first, cultural: it's just a bunch of greybeards opposed to anything and everything new; and second, technical: Rust just doesn't (or didn't) have compiler backends for the same subset of platforms FreeBSD does (or did). (This situation is improving as FreeBSD finally drops official support for obsolete SPARC, 32-bit ARM, MIPS, and 32-bit PowerPC platforms, but obviously cultural barriers remain.)

"Applying Traits to the Smalltalk Collection Classes", 2003 https://rmod-files.lille.inria.fr/Team/Texts/Papers/Blac03a-OOSPLA03-TraitsHierarchy.pdf https://rmod-files.lille.inria.fr/Team/Texts/Papers/Blac03a-... Traits as CS concept, are part of OOP paradigm.

jvanderbot 2y ago
There are shades of OOP, and while you're technically correct I think the meaning of my post is clear.
sshine 2y ago
Traits as CS concept, are part of FP paradigm. Reverse Uno!
- pjmlp 2y ago
  Yes, and someone called Simon Peyton Jones happens to have a talk on how Haskell type classes and classical OOP interfaces interrelate.
  - sshine 2y ago
    Yes, and someone called Gabriella Gonzales happens to have a blog post on how objects are like comonads: https://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html https://www.haskellforall.com/2013/02/you-could-have-invente... And someone called Samuel the Bloggy Badger happens to have another blog posts on how comonads are really more like neighborhoods: https://gelisam.blogspot.com/2013/07/comonads-are-neighbourhoods-not-objects.html https://gelisam.blogspot.com/2013/07/comonads-are-neighbourh... ...so it might all just be a scam!
kccqzy 2y ago
The traits concept mentioned in your link looks very different from Rust traits. It describes something more akin to Java interfaces.
- pjmlp 2y ago
  Java interfaces are based on Objective-C protocols. The only big difference is how implementation is mapped into the trait specification.
  - kccqzy 2y ago
    And that's the problem isn't it? Rust traits are based on GHC type classes, not at all from either Java or Objective-C or Smalltalk.
    - pjmlp 2y ago
      Thankfully this fellow Simon Peyton Jones has a talk about how they map into OOP paradigm. "Classes, Jim, But Not as We Know Them — Type Classes in Haskell: What, Why, and Whither" https://www.microsoft.com/en-us/research/publication/classes-jim-not-know-2009/ https://www.microsoft.com/en-us/research/publication/classes... "Adventure with Types in Haskell" https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=6COvD8oynmI https://www.youtube.com/watch?v=brE_dyedGm0 https://www.youtube.com/watch?v=brE_dyedGm0 On the first lecture he discusses how Haskell relates to OOP in regards of subtyping and generic polymorphism and how although different on the surface they share those CS concepts in their own ways.
      - kccqzy 2y ago
        No. Did you read the contents of the links you shared? The name of the slides in your first link is "Classes, Jim, but not as we know them". And let me quote from the slides in your first link: From slide 40: > So the links to intensional polymorphism are closer than the links to OOP. From the first bullet of slide 43: > No problem with multiple constraints > f :: (Num a, Show a) => a -> ... From the second bullet: > Existing types can retroactively be made instances of new type classes (e.g. introduce new Wibble class, make existing types an instance of it): > class Wibble a where > wib :: a -> Bool > instance Wibble Int where > wib n = n+1 From slide 46: > In Haskell you must anticipate the need to act on arguments of various type > f :: Tree -> Int > vs > f’ :: Treelike a => a -> Int > (in OO you can retroactively sub-class Tree) From slide 50: > In Java (ish): > inc :: Numable -> Numable > from any sub-type of Numable to any super-type of Numable > In Haskell: > inc :: Num a => a -> a > Result has precisely same type as argument I appreciate you sharing informative links even though they prove you wrong. I haven't seen this set of slides before but I find it a very good concise explanation of why Haskell classes are not traditional OOP classes or interfaces.
rmgk 2y ago
Traits in Rust are more a variant of Haskell typeclasses than of Smalltalk traits. The whole FP vs OOP distinction does make little sense these days, as it has mostly been shown that each concept from the one can neatly fit within the other and vice versa.

Asraelite 2y ago

> First class serde. What do you mean? `Serialize` and `Deserialize` are not part of std.

tialaramex 2y ago
It's true, they're not part of the standard library. Nevertheless, it is conventional to provide implementations for things you reasonably expect your users might want to serialize and deserialize. Standard guidance includes telling you to name a feature flag (if you want one for this) serde and not something else so as to reduce extra work for your users. Because Rust's package ecosystem is more robust it's less anxious about the strict line between things everybody must have (in the standard library) and things most people want (maybe or maybe not in the standard library). In C++ there's a powerful urge to land everything you might need in the stdlib, so that it's available. For example the FreeBSD base system includes C++. They're not keen on adding to their base system, so for example they seem disinclined to take Rust, but when each C++ ISO standard bolts in whatever new random nonsense well that's part of C++ so it's in the base system for free. Weird data structure a game dev wants? An entire linear algebra system from Fortran? Comprehensive SI unit systems? It's not up to the FreeBSD gatekeepers, a WG21 vote gets all of those huge requirements into FreeBSD anyway.
- jvanderbot 2y ago
  This was a conscious decision by Rust folks. Let the language and std libraries be small enough to target anything - and let well-established crates (most written/started by the rust folks) fill in functionality. The main language provided the baseline interfaces, in some cases (see async), but not the machinery (e.g., async runtimes).
- loeg 2y ago
  FWIW C++ in FreeBSD is a little contentious. The overall system build time is dominated by Clang, with the rest of FreeBSD "a wart on the side." In base, the C++ compiler was pretty much only used for devd (something vaguely like Linux' udev), and devd is written in a pre-C++11 dialect -- no new features. Using more of it isn't exactly encouraged; it's not allowed in the kernel. There are two significant barriers to Rust in FreeBSD base -- first, cultural: it's just a bunch of greybeards opposed to anything and everything new; and second, technical: Rust just doesn't (or didn't) have compiler backends for the same subset of platforms FreeBSD does (or did). (This situation is improving as FreeBSD finally drops official support for obsolete SPARC, 32-bit ARM, MIPS, and 32-bit PowerPC platforms, but obviously cultural barriers remain.)