Clarify Rust's relationship to OO in the FAQ

[brson]

What is or isn't OO is a complex topic, one that requires a lot of nuance to explain. There are many different conceptions of what OO means. The FAQ doesn't do a good job of making the Rust OO situation clear.

There are two questions on this subject:

• https://www.rust-lang.org/en-US/faq.html#is-rust-object-oriented
• https://www.rust-lang.org/en-US/faq.html#how-do-i-map-object-oriented-concepts-to-rust

They are both rather bare and kinda don't answer the questions, at least not in a satisfying way.

I'd expect them to acknowledge that defining OO is difficult, means different things to different people, various OO concepts can be expressed in various ways with various degrees of fidelity, that if OO means e.g. 'structural inheritance' then basically Rust is not OO, but if that's what you really want then consider this pattern. It might even start off firmly by saying something like 'No, Rust is not an object-oriented language in the way that Java or Smalltalk are; rather, it is a multi-paradigm language that solves some problems using techniques from object-oriented languages, while the solutions to other problems draw influence from other paradigms. Many object-oriented patterns can be represented - some idiomatically, some not - in Rust, but in different forms than one might expect' etc.

cc #467 @AndrewBrinker @JinShil

[alilleybrinker]

Yeah, the answer to this question is going to take some work. @wycats' answer was great, and should probably be the starting point for what goes into the FAQ.

I definitely like his description of the different facets of OO that Rust may be judged against, namely:

• The presence of interfaces, which Rust provides via traits
• The ability to express inheritance hierarchies, which Rust provides (but in a better way!) via trait dependencies
• Data sharing between parents and children in an inheritance hierarchy, which Rust doesn't currently have, but which is being considered in a series of RFCs. (Essentially, we want to make this happen, but don't yet have a clear feeling on the best way to make it happen.)

In addition to these things, I would round out the list of "things some consider to be part of being OO" with the following:

• "Encapsulation" (i.e. the ability for an object to have private data fields), which is absolutely a thing in Rust. It is important to note that the "encapsulation boundary" is at the module level.
• Dynamic dispatch, which Rust offers alongside static dispatch. Probably include here a mention of the fact that static dispatch is often preferable, but dynamic dispatch allows for certain things that static dispatch doesn't (like a container of different types implementing the same trait, via trait objects).

The conclusion would then be something about how even though Rust has many of the trappings of an OO language, the specifics of the design (and the ownership and lifetime systems) mean that things are generally built differently in Rust than they would probably be built in a more traditional OO language like Java or Ruby.

[Ericson2314]

I kind of want the FAQ response to be:

Um, maybe? link-to-wycats-or-similar

[alilleybrinker]

Okay, I finally have some time to work on this! I'll include this in the swath of new answers and answer-improvements I'm working on right now.