6 ms·

In terms of zero cost abstractions, yes. In terms of OOP. No.

tmtvl 4y ago
Does that mean that you don't consider code like... std::args().skip(1).next().unwrap(); ...to be OOP? Because that looks remarkably like some Java code I've written.
- deltasevennine 4y ago
  That's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP. This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
- steveklabnik 4y ago
  The real problem is that OOP has no universally agreed-upon definition. Two of the most popular are what I've nicknamed the "Smalltalk definition" and the "Java definition". Alan Kay, on OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. Java, which I attribute to Java simply because it's very popular and clear about how they think about this: > https://docs.oracle.com/javase/tutorial/java/concepts/ https://docs.oracle.com/javase/tutorial/java/concepts/ defines five core concepts: > * An object is a software bundle of related state and behavior. > * A class is a blueprint or prototype from which objects are created. > * Inheritance provides a powerful and natural mechanism for organizing and structuring your software. > * An interface is a contract between a class and the outside world. > * A package is a namespace for organizing classes and interfaces in a logical manner. This Rust code is missing key aspects of both definitions. The surface syntax may look the same, but the details are different: vs Smalltalk, this is the opposite of late bound, or "messaging": it's all early bound, aka statically dispatched. vs Java, there's no objects here: while there is a method syntax, Rust separates state and behavior, into structs and functions. Methods are functions that support the method call syntax in addition to the regular function syntax. There's no classes here, nor inheritance. There is the use of an interface-like thing, and namespace/package like things. TL;DR: there's more to OOP than method syntax.
wheelerof4te 4y ago
I think people got burnt with OOP one too many times, so they stripped it out in both Go and Rust. Rust still has structs with methods kind of OOP, but you can also have that in C using structs with function pointers. So, not really OOP. Let it die already.
- tialaramex 4y ago
  Object Oriented Programming is a style, like Generic Programming. A language can offer features which support this style well, or not, and you can insist on programming this way regardless of whether the features support it well.
  - deltasevennine 4y ago
    But he's saying the style is bad. Therefore new languages don't support it, well. What do you have to say to that rather then reiterating what everyone knows that OOP is a style of programming.
    - tialaramex 4y ago
      I don't think OOP style is bad but it isn't the choice I'd make in many cases. Accordingly I don't think languages should go out of their way to support this style. In particular Multiple Inheritance is the sort of thing OO languages have (C++ and Python for example) which I am confident is a mistake. If your OO model requires multiple inheritance the model is wrong, go re-design it.
kaashif 4y ago
Rust got rid of inheritance, does that mean it's not OOP? There are effectively still classes, methods, members, interfaces, with all the syntactic sugar that goes along with it. https://doc.rust-lang.org/book/ch17-00-oop.html https://doc.rust-lang.org/book/ch17-00-oop.html It feels like this whole discussion about successors and whatnot is just pointless semantics. Rust fits into a lot of C and C++ use cases and is a good tool to have in your toolbox. C still has its place too.
- deltasevennine 4y ago
  You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not. Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.
  - scratcheee 4y ago
    All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further. The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal. It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.

Does that mean that you don't consider code like... std::args().skip(1).next().unwrap(); ...to be OOP? Because that looks remarkably like some Java code I've written.

deltasevennine 4y ago
That's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP. This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
steveklabnik 4y ago
The real problem is that OOP has no universally agreed-upon definition. Two of the most popular are what I've nicknamed the "Smalltalk definition" and the "Java definition". Alan Kay, on OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. Java, which I attribute to Java simply because it's very popular and clear about how they think about this: > https://docs.oracle.com/javase/tutorial/java/concepts/ https://docs.oracle.com/javase/tutorial/java/concepts/ defines five core concepts: > * An object is a software bundle of related state and behavior. > * A class is a blueprint or prototype from which objects are created. > * Inheritance provides a powerful and natural mechanism for organizing and structuring your software. > * An interface is a contract between a class and the outside world. > * A package is a namespace for organizing classes and interfaces in a logical manner. This Rust code is missing key aspects of both definitions. The surface syntax may look the same, but the details are different: vs Smalltalk, this is the opposite of late bound, or "messaging": it's all early bound, aka statically dispatched. vs Java, there's no objects here: while there is a method syntax, Rust separates state and behavior, into structs and functions. Methods are functions that support the method call syntax in addition to the regular function syntax. There's no classes here, nor inheritance. There is the use of an interface-like thing, and namespace/package like things. TL;DR: there's more to OOP than method syntax.

wheelerof4te 4y ago

I think people got burnt with OOP one too many times, so they stripped it out in both Go and Rust. Rust still has structs with methods kind of OOP, but you can also have that in C using structs with function pointers. So, not really OOP. Let it die already.

tialaramex 4y ago
Object Oriented Programming is a style, like Generic Programming. A language can offer features which support this style well, or not, and you can insist on programming this way regardless of whether the features support it well.
- deltasevennine 4y ago
  But he's saying the style is bad. Therefore new languages don't support it, well. What do you have to say to that rather then reiterating what everyone knows that OOP is a style of programming.
  - tialaramex 4y ago
    I don't think OOP style is bad but it isn't the choice I'd make in many cases. Accordingly I don't think languages should go out of their way to support this style. In particular Multiple Inheritance is the sort of thing OO languages have (C++ and Python for example) which I am confident is a mistake. If your OO model requires multiple inheritance the model is wrong, go re-design it.

kaashif 4y ago

Rust got rid of inheritance, does that mean it's not OOP? There are effectively still classes, methods, members, interfaces, with all the syntactic sugar that goes along with it. https://doc.rust-lang.org/book/ch17-00-oop.html https://doc.rust-lang.org/book/ch17-00-oop.html It feels like this whole discussion about successors and whatnot is just pointless semantics. Rust fits into a lot of C and C++ use cases and is a good tool to have in your toolbox. C still has its place too.

deltasevennine 4y ago
You can twist any language to be OOP if you want. However rust is not primarily focused towards that type of abstraction. Java and C++ are focused towards it. I highly disagree. It is not "pointless semantics". To think everything in the world is some tool in a toolbox and nothing is truly ever bad and everything has a use is naive. Some things are good some things are bad and some things are OOP while other things are not. Rust is not focusing on the OOP philosophy. Both GO and Rust are moving away from that style of abstraction in terms of philosophical goals. If you want to twist the language into OOP that's still possible and still your prerogative. But to deny that the change in philosophy doesn't exist because it's "possible" to do OOP in rust is basically denying the existence of something that CLEARLY exists. I'm not saying OOP is bad. I'm saying that this is the current status quo. My opinion on the OOP style was not mentioned at all.
- scratcheee 4y ago
  All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me. It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further. The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal. It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.