[Twisol]

I don’t think he’s exactly advising any particular action. Rather, data structures and objects tend to be badly conflated, and there’s a lot of value in clarifying the distinction between them. You’ll use each in different circumstances, for different reasons, by weighing the needs of the system against the design tools at your disposal.

In Rust, we keep the same distinction by modeling data structures as structs and enums, and modeling the “object” side by traits (whether static- or dynamic-dispatch). Traits decouple a consumer from the particular data and emphasize a behavioral contract, allowing any data structure to implement the desired behavior.

[sdegutis]

So basically mixins, right? Those were hard to use correctly in Ruby, because you might have multiple whose behavior clash because they can access the same data and were not written with each other in mind. I wonder how Rust solves that.

[Twisol]

Not quite. A mixin is a piece of code written once and transcluded into another module. Traits are more related to OOP interfaces: every type implements one in its own way. The difference with interfaces is that traits can be implemented separately from the definition of the underlying data type, which clarifies the distinction between inherent operations on a specific data structure, and derived operations that bind it to a more general contract of use.

[nercht12]

I really liked the idea of traits in Rust - a kind of interfacing you couldn't get cleanly with C++. The early snag in development there was that the public-vs-private issue couldn't be (sensibly) resolved when a trait was inherited from two "directions" (e.g. modules) - one where it was made public and the other private. It's a problem inherited from C++ and any other OO lang that makes the public/private distinction. I'm sure they've picked a default by now (hopefully public?), but I haven't kept up with it.