8 ms·

Author is correct that Rust is not OOP. It simply has optional dispatch (which does not an OOP language make). I'm sure many of my fellow rustaceans will agree

Author is correct that Rust is not OOP. It simply has optional dispatch (which does not an OOP language make). I'm sure many of my fellow rustaceans will agree that the lack of OOP is one of the most competitive features of Rust.

pjmlp 2y ago
Only those that never picked a Computer Science book on OOP type systems.
- zamalek 2y ago
  Adhod. I have 18 years of professional experience with OOP, all of it a bloody waste of time. Exhibit: https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC
  - pjmlp 2y ago
    Apparently not enough to actually understand OOP type theory.
    - Ygg2 2y ago
      No one that claims to know what OOP is, knows what it means. Because the term is loose and hard to pin down. If OOP encompasses both Smalltalk AND Rust, it's like saying your definition of X includes a neutron star and giraffe. By OOP type theory, you mean category theory? ---- Most what people recognize as OOP today is just Class/Inheritance oriented programming, and Rust doesn't belong in that camp, trying to use structural patterns from that kind of OOP in Rust is often a recipe for disaster.
      - pjmlp 2y ago
        Not at all, OOP type theory is OOP type theory. Not what most people on the street think OOP is all, with their anti-Java bias, rather the Computer Science studies of type systems and their application across all forms of OOP in all programming languages ever invented. Rust has enough features from OOP type systems, regardless of the anti-OOP feeling trying to pretend it doesn't. Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there.
        Ygg2 2y ago
        > Not at all, OOP type theory is OOP type theory. Tell that to Google. OOP type theory returns mostly Category type theory as results. What sources do you have on OOP type theory? Our OOP classes were heavy on practical part and less so on theory. > Rust has enough features from OOP type systems It's missing inheritance. Without inheritance applying OOP design patterns just fails miserably. So on one side you have stuff like Java, C++, JS, Ruby, Python and on the other Rust. > Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there. By that definition, Python isn't object oriented (no encapsulation), and C is. I think it's much more natural to reason about types on what they can do versus some nebulous definition. I mean any language worth its salt will have encapsulation. It's how you preserve your invariants. Method is mostly just syntax sugar. And static/dynamic polymorphism is just a fancy way to say we have function overloading and/or templates and/or vtables (even if using pointer casts).
        pjmlp 2y ago
        Search better, look into SIGPLAN and IEEE papers. Class inheritance is not a requirement for OOP languages. I listed the OOP traits supported by Rust as a language. Naturally you have to nitpick it to try to make a point out of nothing. All high level languages are fancy ways to write machine code.
        Ygg2 2y ago
        > I listed the OOP traits supported by Rust as a language. So is the list missing items? > Naturally you have to nitpick it to try to make a point out of nothing. What did I nitpick? Does Python have encapsulation beyond gentlemen's agreement? Can't C have any of the listed behaviors?
        pjmlp 2y ago
        Python OOP != Rust OOP, but you naturally already knew that. However, in case you need some help, in regards to Python Classe inheritance, function and data members, dynamic dispatch, polymorphism, meta-classes. And even if C doesn't offer direct language support for a OOP type system, that isn't stopping anyone, like the Linux kernel and GNOME/Gtk+. Or publishing books on the matter, http://www.freetechbooks.com/object-oriented-programming-with-ansi-c-t551.html http://www.freetechbooks.com/object-oriented-programming-wit...
  - IshKebab 2y ago
    Come on, it's an automatically generated dependency graphs of `#include`s which is totally useless, but hardly indicative of "a 5 year old being in charge". Absolutely nothing to do with OOP anyway. If you want that look at Java class hierarchies. I found this great art work to illustrate: https://www.researchgate.net/figure/Class-Association_fig3_228968993 https://www.researchgate.net/figure/Class-Association_fig3_2...
echelon 2y ago
Rust is OOP. You can pass &self, self, etc. You can dynamic dispatch. It has a lot of great OOP features. What Rust is not: class-based or inheritance-based (discounting default trait impls). And this is a nice, modern form of OOP that discards orthogonal and useless design baggage.
- zamalek 2y ago
  By that definition nearly every language is OOP, which makes the term useless.
  - k__ 2y ago
    Just because all languages adopted OOP features.
  - deepsun 2y ago
    Yep. All modern general-purpose languages allow to write in object-oriented style.
  - ab5tract 2y ago
    No, it makes the paradigm ubiquitous.
lowbloodsugar 2y ago
I always say it differently: OOP is a paradigm. I've done "object oriented programming" in C and in assembly. Might be more correct to say I've done things like polymorphism in C and assembly. By my definition, Rust can do OOP, even without dyn. I tend to take a very low-level view of things, since I was an assembly programmer before I was a C programmer. I think as Rust broadens its footprint, people are going to have to start using dyn more, and as they do, there'll be new patterns becoming idiomatic. The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally.
- zamalek 2y ago
  > The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally. Rust rapidly becomes painful if you try to OOP in it. You would be better off using an OOP language for OOP. It wasn't voted the most loved language because people enjoyed learning lifetimes alongside all the accidental complexity OOP creates. Dynamic dispatch is mostly seen in two circumstances: the type can't be known at compile time, and reducing code bloat as an optimization step.
  - pjmlp 2y ago
    I ported the famous Raytracing in a Weeked from C++ OOP into Rust OOP, without any issues, code available on my Github. Likewise, Microsoft teams not only didn't had any major issues adding COM tooling support for Rust, it is much easier to deal with COM in Rust, than all the C++ frameworks Microsoft has created throughout the years. Likewise, code available on the official Windows bindings for Rust.
  - lowbloodsugar 2y ago
    Complex vs complicated. Complexity is a property of the problem you are trying to solve. If the problem is complex, the solution is complex. Complicated is a property of the implementation. It happens particularly if the abstractions available in the language of choice can’t represent the complexity of the problem. My impression so far is that Rust is powerful enough to do OOP without issue, but, strangely, doing so is frowned upon, and instead developers add needless complexity to avoid using a feature of the language (dyn).
kibwen 2y ago
Let's be precise about what definition of OOP we're each using. In college, I (and I'm sure many others here) learned that OOP was about "abstraction, encapsulation, inheritance, and polymorphism". But in practice, looking at the history of programming paradigms in industry, it seems like the real success of OOP was in dragging us away from "it's fine for mutable state to be global and/or scattered willy-nilly throughout your code" and towards "mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it". Being generous to the academic definition, we could say that the only pillar of OOP that really mattered was encapsulation. And by that definition, since Rust abhors global mutable state (but not mutation in general, as a functional language might do), it's not unreasonable to say that Rust, even if it doesn't have "objects" as Java or Smalltalk define them, still hews to the most useful parts of OOP.
- logicchains 2y ago
  > "mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it Typical enterprise OOP did the opposite of this, coupling state to unrelated code via inheritance. To quote the creator of Erlang, when you want the banana it gives you the whole forest.
- mrkeen 2y ago
  > towards "mutable state should be localized, tightly scoped, Ironically, the way to do actual encapsulation / localized-mutable-state is to just use stack variables - the C way. Fields (what OOP added) are leakier and less localized than stack variables.
  - kibwen 2y ago
    > just use stack variables - the C way The problem is that C doesn't offer any resistance to using globals rather than stack variables, which led to much of the mess that the OOP revolution of the 80s was supposed to address. For every C program that eschews globals, you have a Toyota Camry, whose control systems famously contained "10,000 global variables" https://news.ycombinator.com/item?id=9643204 https://news.ycombinator.com/item?id=9643204

pjmlp 2y ago

Only those that never picked a Computer Science book on OOP type systems.

zamalek 2y ago
Adhod. I have 18 years of professional experience with OOP, all of it a bloody waste of time. Exhibit: https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC
- pjmlp 2y ago
  Apparently not enough to actually understand OOP type theory.
  - Ygg2 2y ago
    No one that claims to know what OOP is, knows what it means. Because the term is loose and hard to pin down. If OOP encompasses both Smalltalk AND Rust, it's like saying your definition of X includes a neutron star and giraffe. By OOP type theory, you mean category theory? ---- Most what people recognize as OOP today is just Class/Inheritance oriented programming, and Rust doesn't belong in that camp, trying to use structural patterns from that kind of OOP in Rust is often a recipe for disaster.
    - pjmlp 2y ago
      Not at all, OOP type theory is OOP type theory. Not what most people on the street think OOP is all, with their anti-Java bias, rather the Computer Science studies of type systems and their application across all forms of OOP in all programming languages ever invented. Rust has enough features from OOP type systems, regardless of the anti-OOP feeling trying to pretend it doesn't. Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there.
      - Ygg2 2y ago
        > Not at all, OOP type theory is OOP type theory. Tell that to Google. OOP type theory returns mostly Category type theory as results. What sources do you have on OOP type theory? Our OOP classes were heavy on practical part and less so on theory. > Rust has enough features from OOP type systems It's missing inheritance. Without inheritance applying OOP design patterns just fails miserably. So on one side you have stuff like Java, C++, JS, Ruby, Python and on the other Rust. > Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there. By that definition, Python isn't object oriented (no encapsulation), and C is. I think it's much more natural to reason about types on what they can do versus some nebulous definition. I mean any language worth its salt will have encapsulation. It's how you preserve your invariants. Method is mostly just syntax sugar. And static/dynamic polymorphism is just a fancy way to say we have function overloading and/or templates and/or vtables (even if using pointer casts).
        pjmlp 2y ago
        Search better, look into SIGPLAN and IEEE papers. Class inheritance is not a requirement for OOP languages. I listed the OOP traits supported by Rust as a language. Naturally you have to nitpick it to try to make a point out of nothing. All high level languages are fancy ways to write machine code.
        Ygg2 2y ago
        > I listed the OOP traits supported by Rust as a language. So is the list missing items? > Naturally you have to nitpick it to try to make a point out of nothing. What did I nitpick? Does Python have encapsulation beyond gentlemen's agreement? Can't C have any of the listed behaviors?
        pjmlp 2y ago
        Python OOP != Rust OOP, but you naturally already knew that. However, in case you need some help, in regards to Python Classe inheritance, function and data members, dynamic dispatch, polymorphism, meta-classes. And even if C doesn't offer direct language support for a OOP type system, that isn't stopping anyone, like the Linux kernel and GNOME/Gtk+. Or publishing books on the matter, http://www.freetechbooks.com/object-oriented-programming-with-ansi-c-t551.html http://www.freetechbooks.com/object-oriented-programming-wit...
- IshKebab 2y ago
  Come on, it's an automatically generated dependency graphs of `#include`s which is totally useless, but hardly indicative of "a 5 year old being in charge". Absolutely nothing to do with OOP anyway. If you want that look at Java class hierarchies. I found this great art work to illustrate: https://www.researchgate.net/figure/Class-Association_fig3_228968993 https://www.researchgate.net/figure/Class-Association_fig3_2...

echelon 2y ago

Rust is OOP. You can pass &self, self, etc. You can dynamic dispatch. It has a lot of great OOP features. What Rust is not: class-based or inheritance-based (discounting default trait impls). And this is a nice, modern form of OOP that discards orthogonal and useless design baggage.

zamalek 2y ago
By that definition nearly every language is OOP, which makes the term useless.
- k__ 2y ago
  Just because all languages adopted OOP features.
- deepsun 2y ago
  Yep. All modern general-purpose languages allow to write in object-oriented style.
- ab5tract 2y ago
  No, it makes the paradigm ubiquitous.

lowbloodsugar 2y ago

I always say it differently: OOP is a paradigm. I've done "object oriented programming" in C and in assembly. Might be more correct to say I've done things like polymorphism in C and assembly. By my definition, Rust can do OOP, even without dyn. I tend to take a very low-level view of things, since I was an assembly programmer before I was a C programmer. I think as Rust broadens its footprint, people are going to have to start using dyn more, and as they do, there'll be new patterns becoming idiomatic. The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally.

zamalek 2y ago
> The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally. Rust rapidly becomes painful if you try to OOP in it. You would be better off using an OOP language for OOP. It wasn't voted the most loved language because people enjoyed learning lifetimes alongside all the accidental complexity OOP creates. Dynamic dispatch is mostly seen in two circumstances: the type can't be known at compile time, and reducing code bloat as an optimization step.
- pjmlp 2y ago
  I ported the famous Raytracing in a Weeked from C++ OOP into Rust OOP, without any issues, code available on my Github. Likewise, Microsoft teams not only didn't had any major issues adding COM tooling support for Rust, it is much easier to deal with COM in Rust, than all the C++ frameworks Microsoft has created throughout the years. Likewise, code available on the official Windows bindings for Rust.
- lowbloodsugar 2y ago
  Complex vs complicated. Complexity is a property of the problem you are trying to solve. If the problem is complex, the solution is complex. Complicated is a property of the implementation. It happens particularly if the abstractions available in the language of choice can’t represent the complexity of the problem. My impression so far is that Rust is powerful enough to do OOP without issue, but, strangely, doing so is frowned upon, and instead developers add needless complexity to avoid using a feature of the language (dyn).

kibwen 2y ago

Let's be precise about what definition of OOP we're each using. In college, I (and I'm sure many others here) learned that OOP was about "abstraction, encapsulation, inheritance, and polymorphism". But in practice, looking at the history of programming paradigms in industry, it seems like the real success of OOP was in dragging us away from "it's fine for mutable state to be global and/or scattered willy-nilly throughout your code" and towards "mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it". Being generous to the academic definition, we could say that the only pillar of OOP that really mattered was encapsulation. And by that definition, since Rust abhors global mutable state (but not mutation in general, as a functional language might do), it's not unreasonable to say that Rust, even if it doesn't have "objects" as Java or Smalltalk define them, still hews to the most useful parts of OOP.

logicchains 2y ago
> "mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it Typical enterprise OOP did the opposite of this, coupling state to unrelated code via inheritance. To quote the creator of Erlang, when you want the banana it gives you the whole forest.
mrkeen 2y ago
> towards "mutable state should be localized, tightly scoped, Ironically, the way to do actual encapsulation / localized-mutable-state is to just use stack variables - the C way. Fields (what OOP added) are leakier and less localized than stack variables.
- kibwen 2y ago
  > just use stack variables - the C way The problem is that C doesn't offer any resistance to using globals rather than stack variables, which led to much of the mess that the OOP revolution of the 80s was supposed to address. For every C program that eschews globals, you have a Toyota Camry, whose control systems famously contained "10,000 global variables" https://news.ycombinator.com/item?id=9643204 https://news.ycombinator.com/item?id=9643204