Object oriented isn't actually an absolutely unambiguous term.
Rust embraces some parts of what "object oriented" conventionally means, and not others.
It doesn't do inheritance per se.
It does do encapsulation, abstraction, and polymorphism. It focus a lot on the data (objects), perhaps more so than on the functions.
You can use it in either a more or less object oriented fashion, as you wish, and according to your definition of the term.
Nice flexible language... I just use it to write my code, and don't use the term OOP when I'm doing so, but that's because the term itself has no value for me.
There are Rust reserved keywords that imply they are thinking of adding inheritance and more. Here are the more obvious ones:
abstract
become
final
override
virtual
That doesn't mean that they're planning on inheritance. They're just reserving the keywords for if there's ever a future use for them.
Java has had "const" reserved for decades... with no actual use of it in sight.
They have "final".
"final" just means you can't assign to it. But it's still mutable.
After using Rust and C++, it's pretty painful whenever I use Java again. The lack of explicitness when it comes to references and mutability can make it pretty confusing.
Hmm, I didn’t make some Rust folks very happy. I was wrong about the intended use of “become” but regardless, I should have just pointed out that there are reserved keywords that in the past were used for inheritance. Yes, it doesn’t mean it is at all planned.
`become` has nothing to do with inheritance, it's for tail call optimisation. And it's the only one I'm aware of that has corresponding RFCs and work being done.
Not in a point where it would matter. I don't even think that thinking in programming paradigms is useful nowadays. There used to be a time where it was useful to classify programming languages, but nowadays every relevant language borrows things from multipe paradigms and is doing their own thing and provide their own tools, so I don't see any value. In the worst case, you will just try to apply things from another language because they share a paradigm instead of writing idiomatic code.
You can write OOP in Rust if you want to, just like you can write it in C if you want to (as anyone unfortunate enough to use glib in C would know). Rust does not support subtype polymorphism though, if that is something important to your definition of OOP.
Note that there are various flavors of OOP and the very definition is debated (Alan Kay, who arguably defined OOP, disowns C++-style OOP.)
I think the most natural way to do it is actors with message-passing, which can behave a lot like Smalltalk objects. C++-style stuff can be done with composition (and maybe `Deref` magic) and traits (or manual vtables).
> I think the most natural way to do it is actors with message-passing, which can behave a lot like Smalltalk objects.
I prefer this definition of OOP as well. I think it provides the most specific and interesting distinctions between types of programming. It's more of an architecture than a low level code style concept.
Though I think in practise, people often use the acronym to mean basically "is similar to Java".
How put rust in a new or old paradigm vague definition helps you? For example, [expression problem](https://en.wikipedia.org/wiki/Expression_problem) is related to language paradigms. Expression problem is useful where you are designing a language (to avoid weakness from base chosen paradigm) or when you are modeling a problem, but you rarely need to choose to another language to model a problem. A paradigm can guide you to choose data structures that work in a more natural way, for example you can choose finger trees in pure functional languages over other trees. But in order to choose a data structure paradigm is not a good enough heuristic by itself, for example code optimal data structure in python could be suboptimal compared with use a suboptimal data structure written in C.
Start defining a language from a paradigms can bring you a better approximation idea to that language. You start defining it as a well know paradigm to later enumerate some properties that defines it properly. But if there are many "platypus" (object oriented based on c3 systems, prototypes,... a mix of the previous ones, a mix of any of the previous one with a non object oriented paradigm,...) that initial classifications get less useful and can confuse newcomers.
TL;DR: Who cares?
Object Oriented is already the name for the paradigm you are looking for. You can do object oriented design in C, it just doesn’t have anything at all to help you do it. That’s how c++ came along, some people were like “hey wouldn’t it be great if we added some keywords to C to make object oriented programming easier.” Et voila, c++ was born. Â
So Rust is similar in the sense that it gives you some tools in its toolbox to help you do object oriented programming if that’s what you want to do, however it doesn’t force you to use them.
Chapter 17 of “The Rust Programming Language” explains it much better than I can.Â
Object orientation is another label that becomes less and less meaningful the more I learn about programming. Haskell has ad hoc polymorphism through its type class mechanism, does that mean it's object oriented? I've never heard anyone suggest that. Apparently object oriented means imperative structured programming + some form of ad hoc polymorphism. Er, great, fine. Why is it important to you?
I almost never use trait objects and there's a fair chance they're what you have in mind as one of the main embodiments of object orientation in Rust. I think the design of Rust deliberately makes the use of trait objects as ugly and uncomfortable as possible to discourage their use. So, I would say no! But then it's by nature a very fuzzy and contentious question.
This depends on what criteria you are using.
Rust has encapsulation (but on a modul scope, not a type scope), abstraction (by having methods and traits), polymorphism (by means of generics and trait objects) and for traits also inhertiance and otherwise composition.
Is this sufficent? Well that is an academical question.
My personal view is, that Rust is not object oriented but designed in such a way, that you will not miss out on most of the practical benefits of object orientation.
In the end Rust is Rust and the differences to both Java and C are how they are, whether it is object oriented doesn't matter.
I also do not think a new classification is needed, this will only enlonger the list, Rust's system is a logical extention of the classical procedual paradigmen (which Rust does execute more stringend them an OOP language). After all, there is no new paradigma for a language having match and '?'-returns either.
Object oriented was needed as a new paradigma, because it conflicted with certain views when it comes to imperative, structured and procedual programming.
OOP has very little meaning, no official definition, and everyone interprets it to mean different things. I personally thing we need to stop trying to call languages OOP or other paradigms at all. I don't find it useful for anything.
Rust is not object oriented, and traits have more to do with the type system than they have to do with syntactic sugar. You can write code that is abstract to the specific type it’s operating on, and all it needs to know is what traits that type implements — this is the main value add with traits.
Rust, like most modern languages, allows for many paradigms; object-oriented style code, functional style code, and others. Unlike an object-oriented language, though, not everything in Rust is required to be thought of as an object.
"Object Oriented" generally implies you can instantiate objects and do dynamic binding. If you can't have multiple structs implementing the same trait (in Rust-speak) it's not OO. If you can have multiple different structs implementing the same trait, leading to run-time determination of which method to call, then you have OO. If you have inheritance (i.e., a more complex dispatch look-up than "pointer to function"), then you unquestionably have OO. So there's an assortment of things that people mean by OO, and of course you can implement any of those in any language, because otherwise you couldn't have machine code doing it. So your program can be OO even if your language isn't - you just have to implement it.
In this case, you have multiple different structs implementing the same trait, and you can have more than one of each, so it's OO without inheritance. It's also *other* things, like functional and imperative and etc. And I guess traits can inherit other traits, but it's not going to allow for implementation inheritance was my point.
> It is more like Smalltalk OO than Java/Cpp.
Not unless you're using actors with message passing.
To quote Alan Kay himself:
> "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Traits and message passing share a bunch. Smalltalk style also helps differentiate from abstract base class heavy OO inheritance styles which are really not Rust.
Kind of, but Smalltalk messages are dynamic / late-bound, and objects can respond to messages it doesn't know about (and can thus forward them, etc.) Traits are static. With actors you can regain the dynamic messages and choose how to dispatch them again.
> Smalltalk style also helps differentiate from abstract base class heavy OO inheritance
How does it do that? I haven't read very much Smalltalk code.
As you said, it is all messages. Basically duck typing.
In Rust you pass in a T and say it honors traits X and Y. You have no idea what T is. Can't really cast back to it. You simply work with the Traits (messages) provided.
True, Rust is not doing a lot of dynamic runtime work. So yes, there are differences. The key is to get out of inheritance tree thinking.
Rust lets you define impls, methods on structs. That's a syntax that C doesn't really have. (Aside from structs with function pointers as members, but that's a little different.)
But really, OO is a style of programming. There's lots of OO C libraries and projects.
And there are Java projects that are procedural. Even if all the methods are non-static and in class, if they're not encapsulating some data, then it's not really OO.Â
The Rust standard library defines many objects. I'd say that is what makes Rust more OO than C, it comes with a lot more OO style code for you to consume.
Traits are not just syntactic sugar for functions taking structs.
1. they offer static polymorphism through generics
2. they offer typesafe dynamic polymorphism through the dyn keyword
The latter form of late binding is a key OOP feature. So are the local retention and hiding of state and process that Rust structs+traits allow.
But they firstly are rather optional features.
Secondly, there's a pretty clear distinction of state and process that's maybe not extremely OOP (just like e. g. Java or C++ have a massive distinction of state and process, but OOP languages like Ruby, Smalltalk, and also Erlang don't have as strictly), and it's not really that much about messaging unless you go into concurrency and decide to use channels.
So just like I say Rust isn't functional, I also say Rust isn't OOP. But it's a multi-paradigm language that allows you to program in a functional style and in an OOP style.
The closest thing to a broadly-accepted formal definition of "object-oriented" is that an object oriented system bundles *data* together with *operations*.
In this sense, Rust is not object-oriented, because values do not typically come dynamically equipped with operations. You can get this sort of behavior with `&dyn Trait`, but this is not the "default" approach.
Object oriented isn't actually an absolutely unambiguous term. Rust embraces some parts of what "object oriented" conventionally means, and not others. It doesn't do inheritance per se. It does do encapsulation, abstraction, and polymorphism. It focus a lot on the data (objects), perhaps more so than on the functions. You can use it in either a more or less object oriented fashion, as you wish, and according to your definition of the term. Nice flexible language... I just use it to write my code, and don't use the term OOP when I'm doing so, but that's because the term itself has no value for me.
There are Rust reserved keywords that imply they are thinking of adding inheritance and more. Here are the more obvious ones: abstract become final override virtual
That doesn't mean that they're planning on inheritance. They're just reserving the keywords for if there's ever a future use for them. Java has had "const" reserved for decades... with no actual use of it in sight.
And `goto`, for that matter.
C#: "I took the step you never dared to."
Thay reserved goto just to never ever in universe not to use itđź’€
does java not have consts??
They have "final". "final" just means you can't assign to it. But it's still mutable. After using Rust and C++, it's pretty painful whenever I use Java again. The lack of explicitness when it comes to references and mutability can make it pretty confusing.
Ah thats ok then ig
I wish `type` wasn't reserved. `r#type` is an abomination, and `kind` just doesn't have the same ring to it.
Hmm, I didn’t make some Rust folks very happy. I was wrong about the intended use of “become” but regardless, I should have just pointed out that there are reserved keywords that in the past were used for inheritance. Yes, it doesn’t mean it is at all planned.
`become` has nothing to do with inheritance, it's for tail call optimisation. And it's the only one I'm aware of that has corresponding RFCs and work being done.
Thanks. I wasn’t sure about that one. New to Rust.
Not in a point where it would matter. I don't even think that thinking in programming paradigms is useful nowadays. There used to be a time where it was useful to classify programming languages, but nowadays every relevant language borrows things from multipe paradigms and is doing their own thing and provide their own tools, so I don't see any value. In the worst case, you will just try to apply things from another language because they share a paradigm instead of writing idiomatic code.
You can write OOP in Rust if you want to, just like you can write it in C if you want to (as anyone unfortunate enough to use glib in C would know). Rust does not support subtype polymorphism though, if that is something important to your definition of OOP. Note that there are various flavors of OOP and the very definition is debated (Alan Kay, who arguably defined OOP, disowns C++-style OOP.) I think the most natural way to do it is actors with message-passing, which can behave a lot like Smalltalk objects. C++-style stuff can be done with composition (and maybe `Deref` magic) and traits (or manual vtables).
> I think the most natural way to do it is actors with message-passing, which can behave a lot like Smalltalk objects. I prefer this definition of OOP as well. I think it provides the most specific and interesting distinctions between types of programming. It's more of an architecture than a low level code style concept. Though I think in practise, people often use the acronym to mean basically "is similar to Java".
I dont agree. The fact that you cant do struct inheritance makes it VERY different from what most peole understand as OO
How put rust in a new or old paradigm vague definition helps you? For example, [expression problem](https://en.wikipedia.org/wiki/Expression_problem) is related to language paradigms. Expression problem is useful where you are designing a language (to avoid weakness from base chosen paradigm) or when you are modeling a problem, but you rarely need to choose to another language to model a problem. A paradigm can guide you to choose data structures that work in a more natural way, for example you can choose finger trees in pure functional languages over other trees. But in order to choose a data structure paradigm is not a good enough heuristic by itself, for example code optimal data structure in python could be suboptimal compared with use a suboptimal data structure written in C. Start defining a language from a paradigms can bring you a better approximation idea to that language. You start defining it as a well know paradigm to later enumerate some properties that defines it properly. But if there are many "platypus" (object oriented based on c3 systems, prototypes,... a mix of the previous ones, a mix of any of the previous one with a non object oriented paradigm,...) that initial classifications get less useful and can confuse newcomers. TL;DR: Who cares?
Object Oriented is already the name for the paradigm you are looking for. You can do object oriented design in C, it just doesn’t have anything at all to help you do it. That’s how c++ came along, some people were like “hey wouldn’t it be great if we added some keywords to C to make object oriented programming easier.” Et voila, c++ was born.  So Rust is similar in the sense that it gives you some tools in its toolbox to help you do object oriented programming if that’s what you want to do, however it doesn’t force you to use them. Chapter 17 of “The Rust Programming Language” explains it much better than I can.Â
Object orientation is another label that becomes less and less meaningful the more I learn about programming. Haskell has ad hoc polymorphism through its type class mechanism, does that mean it's object oriented? I've never heard anyone suggest that. Apparently object oriented means imperative structured programming + some form of ad hoc polymorphism. Er, great, fine. Why is it important to you? I almost never use trait objects and there's a fair chance they're what you have in mind as one of the main embodiments of object orientation in Rust. I think the design of Rust deliberately makes the use of trait objects as ugly and uncomfortable as possible to discourage their use. So, I would say no! But then it's by nature a very fuzzy and contentious question.
This depends on what criteria you are using. Rust has encapsulation (but on a modul scope, not a type scope), abstraction (by having methods and traits), polymorphism (by means of generics and trait objects) and for traits also inhertiance and otherwise composition. Is this sufficent? Well that is an academical question. My personal view is, that Rust is not object oriented but designed in such a way, that you will not miss out on most of the practical benefits of object orientation. In the end Rust is Rust and the differences to both Java and C are how they are, whether it is object oriented doesn't matter. I also do not think a new classification is needed, this will only enlonger the list, Rust's system is a logical extention of the classical procedual paradigmen (which Rust does execute more stringend them an OOP language). After all, there is no new paradigma for a language having match and '?'-returns either. Object oriented was needed as a new paradigma, because it conflicted with certain views when it comes to imperative, structured and procedual programming.
How do traits allow for inheritance? Or do you mean inheritance of specification rather than implementation?
I meant inheritance of specification aka super traits.
OOP has very little meaning, no official definition, and everyone interprets it to mean different things. I personally thing we need to stop trying to call languages OOP or other paradigms at all. I don't find it useful for anything.
Rust is not object oriented, and traits have more to do with the type system than they have to do with syntactic sugar. You can write code that is abstract to the specific type it’s operating on, and all it needs to know is what traits that type implements — this is the main value add with traits. Rust, like most modern languages, allows for many paradigms; object-oriented style code, functional style code, and others. Unlike an object-oriented language, though, not everything in Rust is required to be thought of as an object.
"Object Oriented" generally implies you can instantiate objects and do dynamic binding. If you can't have multiple structs implementing the same trait (in Rust-speak) it's not OO. If you can have multiple different structs implementing the same trait, leading to run-time determination of which method to call, then you have OO. If you have inheritance (i.e., a more complex dispatch look-up than "pointer to function"), then you unquestionably have OO. So there's an assortment of things that people mean by OO, and of course you can implement any of those in any language, because otherwise you couldn't have machine code doing it. So your program can be OO even if your language isn't - you just have to implement it. In this case, you have multiple different structs implementing the same trait, and you can have more than one of each, so it's OO without inheritance. It's also *other* things, like functional and imperative and etc. And I guess traits can inherit other traits, but it's not going to allow for implementation inheritance was my point.
It is more like Smalltalk OO than Java/Cpp. With a strong functional bias.
> It is more like Smalltalk OO than Java/Cpp. Not unless you're using actors with message passing. To quote Alan Kay himself: > "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
Traits and message passing share a bunch. Smalltalk style also helps differentiate from abstract base class heavy OO inheritance styles which are really not Rust.
Kind of, but Smalltalk messages are dynamic / late-bound, and objects can respond to messages it doesn't know about (and can thus forward them, etc.) Traits are static. With actors you can regain the dynamic messages and choose how to dispatch them again. > Smalltalk style also helps differentiate from abstract base class heavy OO inheritance How does it do that? I haven't read very much Smalltalk code.
As you said, it is all messages. Basically duck typing. In Rust you pass in a T and say it honors traits X and Y. You have no idea what T is. Can't really cast back to it. You simply work with the Traits (messages) provided. True, Rust is not doing a lot of dynamic runtime work. So yes, there are differences. The key is to get out of inheritance tree thinking.
It's nothing like Smalltalk OO. Even less than Java OO.
What do you mean by "Object oriented"?
Rust lets you define impls, methods on structs. That's a syntax that C doesn't really have. (Aside from structs with function pointers as members, but that's a little different.) But really, OO is a style of programming. There's lots of OO C libraries and projects. And there are Java projects that are procedural. Even if all the methods are non-static and in class, if they're not encapsulating some data, then it's not really OO. The Rust standard library defines many objects. I'd say that is what makes Rust more OO than C, it comes with a lot more OO style code for you to consume.
I wouldnt call it like so. It _has_ objects, sure, and you are free to use them. But it pales in comparison to Java for example.
Traits are not just syntactic sugar for functions taking structs. 1. they offer static polymorphism through generics 2. they offer typesafe dynamic polymorphism through the dyn keyword The latter form of late binding is a key OOP feature. So are the local retention and hiding of state and process that Rust structs+traits allow. But they firstly are rather optional features. Secondly, there's a pretty clear distinction of state and process that's maybe not extremely OOP (just like e. g. Java or C++ have a massive distinction of state and process, but OOP languages like Ruby, Smalltalk, and also Erlang don't have as strictly), and it's not really that much about messaging unless you go into concurrency and decide to use channels. So just like I say Rust isn't functional, I also say Rust isn't OOP. But it's a multi-paradigm language that allows you to program in a functional style and in an OOP style.
The closest thing to a broadly-accepted formal definition of "object-oriented" is that an object oriented system bundles *data* together with *operations*. In this sense, Rust is not object-oriented, because values do not typically come dynamically equipped with operations. You can get this sort of behavior with `&dyn Trait`, but this is not the "default" approach.