For me it was the web-of-pointers strategy I had to unlearn. A child object keeping a pointer to its parent is misery in Rust. It forces you to either make the child completely independent or really prove the parent will be around until the child disappears.

90% of the time this is dumb overhead, but 10% of the time it found a bug in some edge case, so I learned to appreciate it as a tough teacher, and my designs got better for it.

We solved this with flat vectors and just sharing index values in cheap walker objects. It is much nicer to work with compared to arc/weak pointers.

Code here: https://github.com/prisma/prisma-engines/tree/main/libs%2Fda...

How is this fundamentally different from raw pointers?

Not OP

It serializes better, it's memory safe, it can be much faster in performance terms, you can get better memory usage if you're holding a lot of "pointers" because the indexes don't need to be 64 bits.

But you lose all ownership tracking / safety that Rust is famous for.

I just can't help but wonder what it means for that paradigm, when the most popular answer to "how do I model my entities in safe Rust" is basically "backdoor the safety".

Which way did you go, (1) not use pointers from child to parent (functional programming approach), or (2) kept using such pointers but made it work? Your first paragraph sounds like (1), but the second sounds like (2).

If it was (2), it sounds like you made it work without unsafe code? Can you share some code?

> designs got better for it.

What is better about them?

>"90% of the time this is dumb overhead, but 10% of the time it found a bug in some edge case, so I learned to appreciate it as a tough teacher, and my designs got better for it."

Sounds kind of like Stockholm syndrome

And you sound like you are part of the reason why we still have exploitable null-pointer bugs in 2022. Imagine a structural engineer that would say "all that static and dynamic analysis is dumb overhead 90% of the time, so I am going to skip it". Imagine an electrical engineer who would go like "all these wire gauge calculations are exhausting, 90% of the time my installations don't catch fire"

Seriously, I sometimes wonder what is wrong with the whole field of software development.

Nothing is wrong. Same shit as in any other area. It is a usual trade-off between what you pay and what you get in return, some of it highly politicized.

> Rust actually supports most OOP features, with the main exception of implementation inheritance.

I've tried some basic OOP.

Fields from the base class need to be redefined in each child, and making shared methods private require an ugly workaround. Both concepts are very basic OOP concepts, not advanced or inherently/tendentially dangerous, and the results is that even basic Rust OOP requires a lot of boilerplate. It's workaroundable with macros if one wants, although they have some limitations, and I guess this is the reason why the macro approach is not widespread.

Some devs use composition to emulate it, but the result is another form of boilerplate (very noisy builder patterns).

Regarding "non-basic" OOP features, I remember that Rust GUI framework programmers uniformly complain about Rust not being appropriate to translate the OOP hierarchies typically used in GUI frameworks, so the gap is significant (this is not inherently bad; not supporting OOP can be a respectable choice, but matter of factually, this does create a gap in some cases).

You can define a field with the type of the base class in the subclass, and impl Deref for SubClass, with Target = BaseClass.

You can, but the docs for Deref beg you not to use Deref for types that aren’t smart pointers because of how confusing and surprising the results can be to an unfamiliar reader of the code.

Rust itself does not have much support for delegation (the building block for the features you're referring to) since it's pretty much syntactic sugar anyway, but you can use crates like 'ambassador' to provide that.

The idea of object inheritance is silly. If you need a 'base' class A for data type B just do

    struct B {
      a: A
    }

Does OOP require inheritance?

Kind of, it needs the ability to express polymorphism and extend concepts.

Now how that is done is practice, can be done in various ways.

Class inheritance, which is what many think of.

Interface inheritance or conformance, which is available in many languages via traits, patterns, data classes, functors, or other names, and OS ABIs like COM.

Prototype inheritance, clone a instance and monkey patch in place (like SELF)

Via composition and delegation for not handled messages.

Then many languages offer a combination of those approaches.

For me, one of the main reasons to use OOP is dynamic dispatch / runtime polymorphism. I have not spent much time with Rust, but it seems like that is a bit cumbersome there, and doesn't exactly work like you would expect from Java, C++, Python, ....

I mostly use OOP when I have a bunch of Foos and Bars, and want to treat them differently in some places. Instead of having ifs in each function, I use inheritance, and override the methods that I want to treat differently. It's mostly about heterogenous containers and avoiding explicit ifs. When you use it that way, it's safe and convenient and I've never ran into the fragile base class problem or other typical issues.

It definitely works differently to C++/Java/Python, but IMO this is one place where Rust is a huge improvement. You are effectively always generic over an interface (trait in Rust) rather than a base class, and this is much more flexible as a given strict can implement as many interfaces as it likes rather than being stuck in one class hierarchy (or having to deal with the pain of multiple inheritance)

It is no different than using interfaces, protocols, pure virtual base classes....

It's similar, but there are some differences. Notably, my package can implement my trait for your type, while my package (usually? always?) cannot make your type inherit from my virtual base class.

Depends on the flexibitly of the language, there isn't a golden way to do that across all variations of OOP.

Wrapper classes should be equally good once Valhalla (jdk) lands, without introducing another pointer indirection.

Interesting but Java gets more and more complex in a way that does not make me want to write things in Java.

Not a Rust expert but: doesn't Rust support this use-case via Box<dyn SomeTrait> , and leveraging default Trait methods, only overriding the defaults you want to for each type implementing the Trait?

What you describe can be achieved in Java via composition (instead of inheritance) and using interfaces.

Does it?

I've seen it being repeated ad nauseam without any concrete backing.

I mean it has some OOP concepts. But it's mostly in traits. Saying Rust is OOP is a bit like saying Chimera is a Goat.

Anyone that tried to use OOP in Rust, knows it's next to impossible.

Yes it does, OOP is a spectrum not "like Java does it".

I'd consider something OOP if it has the same expressive power i.e. things expressible in OOP languages are easily expressible in another OOP language as well. And for Rust that's not the case.

Otherwise you end up with Haskell is an OOP language.

I will debate it is one, yes.

Just like being an FP language isn't "like Haskell does it", when I learned FP, Haskell didn't even exist.

Try to express Eiffel, CLOS, SELF or BETA in Java.

By the way, here is One Weekend Raytracing in Rust, perfectly using OOP with dynamic dispatch and interfaces (sorry traits).

https://github.com/pjmlp/RaytracingWeekend-Rust

Ok. But noticed what I said. *Things* that are easy in one OOP should be similarily easy to express in other OOP language.

Counter example: Html5 DOM.

Counter example of what?

A graph representation of nodes based on JavaScript object model?

Fine, https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.ht...

Yeah but if you dig deeper you'll notice it is riddled with unsafe, casts and Deref misuse.

It's a brittle simulation of Inheritance. To transform a saying "Just because you can write Ada in C, doesn't make C Ada".

Post Scriptum: one way to prove this is that we could use https://www.youtube.com/watch?v=43XaZEn2aLc as a base.

How to prove.

Assume that we add struct inheritance to Rust (it looks similar to JS) - call it RustInh.

Does adding inheritance to Rust increase expressive power? If yes, then right now Rust can't express OOP concept as inheritance. I.e. is there a C[RustInh] = C[Rust].

And way to prove it is to look at Deref anti-patterns https://github.com/rust-unofficial/patterns/blob/main/anti_p...

I'm still not sure that fully captures my intuition of easy to write.

> I'd consider something OOP if it has the same expressive power i.e. things expressible in OOP languages are easily expressible in another OOP language as well.

That doesn't even make sense on its face. There are things which are trivially expressible in Smalltalk and I'm not sure even possible to wrangle in Java.

That's because Smalltalk OOP isn't the OOP in the sense Java is, some refer to Java Style as Class oriented Programming.

That doesn’t make your original comment any less nonsensical, and still makes no sense: Smalltalk is very much class-based. Are you mixing up Smalltalk and Self?

To me, OOP always meant passing messages to objects, but it seems everyone has their own definition depending on experience.

> fragile base class problem

I do wonder whether this is as much of a problem as people think. Most of the time it only becomes a problem when people start doing stupid things to override the parent instead of refactoring a new class out from under it.