If Rust is not an Object Oriented Programming language, what is it oriented to? Features? Modules?
Rust is OOP. The book has a chapter on this subject: Characteristics of Object-Oriented Languages - The Rust Programming Language
Rust does also borrow from functional languages though.
It is oriented to many programming paradigms. I'd say it's:
- About 25% Functional
- About 25% Object oriented
- About 50% Trait oriented
So it's mostly trait oriented.
And since it's not 100% of any of those, some of the approaches that work with one of those paradigms don't work for Rust. For OOP the major difference is probably in inheritance. I suggest reading the second Rust koan to get some insight into the rationale for this difference.
To add some more things, I'll show some examples where rust is kind of like an OOP (And comparing to C#, which is what I happen to have experience with):
- You can upcast to a trait object, similar to casting a
Derived
toInterface
in C#. This must be kept under a pointer though, because we don't have variable stack size (Yet.) - You can kind of downcast if your object implements
Any
. (So essentially anything that has either no references or static references) - You can implement a trait you define locally on anything, rather than the interface/abstract class needing to be implemented at the declaration site.
while in rustinterface Foo {} class Bar: Foo { //Implement Foo here }
//library A: struct Bar {} //Library B: trait Foo {} impl Foo for Bar {} //Woo hoo, now Bar magically implements Foo.
- There really isn't a notion of a reference type vs a value type. It is very very clear when we're passing something that is owned or something that is not. Therefore you can tell when moving an object into another function or passing it around repeatedly is fast or if it would be faster to pass a reference around while C# for example just whisks it away with the GC.
- Constructor functions aren't a language built-in. We use object construction notation where we specify all of the fields of a struct at the time of creation, meaning we cannot have half-constructed objects safely. Instead the norm is to include a
::new()
function which will construct the object for you. And/Or implementDefault
.
Since most programming languages have wildly diverged from the original definition of their (main) paradigm (ironically, OO is probably one of the best examples of the phenomenon), and since almost everyone defines these words differently anyway, I find it largely pointless to ask questions of the form "Is X a Y-oriented language?", and even more so to answer them with a simplistic "yes/no". To that end:
Rust is…
- …a language whose main goal and promise is to bring compile-time-proven memory safety and thread safety together with runtime performance, ideally without compromising either;
- …which is achieved via a unique combination of half-century-old and novel good ideas from the history of programming language design; drawing heavily on
- …interface-/protocol-/typeclass-/trait-/whatever-you-call-it- based programming complementing real, parametric polymorphism aka "generics" aka "type-level functions";
- …making the strong static typing easier to digest for the programmer via extensive and smart type inference;
- …mixing in the basics of algebraic type systems found in traditional statically-typed so-called functional languages, such as Haskell and its family;
- …as well as the superb pattern matching abilities of said languages;
- …allowing as syntactic sugar for function calls what many consider "THE object-oriented syntax";
- …although the latter was never the essence of object-oriented programming – according to some, myself included, it is instead encapsulation, which Rust also provides via the simple concept of visibility modifiers;
- …while it also cleverly manages mutable state, allowing for the so-called procedural-imperative paradigm to be embedded into the language without undermining its safety.
As you can see, that's quite a mouthful; in my opinion, every one of these is an important (although probably not equally important) building block of the language, and I rely on almost every single one of them in my daily Rust programming. Furthermore, I observed two changes in my own programming style after digging deeper in Rust:
- It is nothing exactly like the preferred idioms of any other language, but each of its features brings in and improves upon a certain style that is connected to the language where said feature was borrowed from.
- I increasingly miss the ability to follow these idioms when I work in other languages.
OK but I just need to fill in a stupid quiz for an Intro to Programming course, so please just tell me if Rust is OO or not!
In this case I'd lean towards "no". At least it's not the main, most prominent characteristic of the language. Instead of being religious about the One Right Way to do things architecture-wise, I think Rust is pretty malleable and fits many (sensible) styles well, as long as it leads to the highest possible degree of correctness. Oh, yeah, it's however pretty darn opinionated about how you should deal with your mutable pointers. I'll give you that maybe it should be called an "RWLock-oriented language", then.
I think the thing that confuses people is that Rust isn't class-based OOP. Most people come to Rust from a C++
/Python
/Java
/C#
/etc background so that's the perspective they have. If you try to program in Rust the same way as you do using classes, then you're going to run into problems and get frustrated.
Funnily enough people had a similar problem with Javascript's style of OOP. The "solution" there was to glue the class
keyword on top of the whole thing and call it a day.
But anyway, all these languages are really multi-paradigm. You can often use procedural style or functional style to a greater or lesser extent. And from a theoretical point of view, merely sticking functions and variables into a class doesn't mean you're doing OOP.
Rust is also multi-paradigm, with good support for some functional programming styles (although people coming from Haskell et al might be disappointed if they expect too much).
I'm going to slightly disagree with @H2CO3 in that I think Rust does sort of encourage using an OOP style to at least the extent that you use standard library objects (e.g. Vec
, Path
, etc).
Coming from OOP, you may find this success tale interesting. It's one of my favorites.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.