I just started learning rust like two days ago and I haven’t had too many issues with OOP so far… is it going to get considerably worse as the complexity of my projects increases?

[–] Ephera@lemmy.ml 8 points 3 days ago (1 children)

The thing with OOP, particularly how it's used in GCed languages, is that it's all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it's modified in asynchronous code.

Rust has quite the opposite mindset. It's all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don't need them.

[–] bestboyfriendintheworld@sh.itjust.works 1 points 2 days ago (1 children)

OOP also has object ownership hierarchy structures. Which object owns which other object, is a question always worth answering.

[–] Ephera@lemmy.ml 1 points 2 days ago (1 children)

Hmm, not sure, if I've heard of it. I'm guessing, we're not talking about simply drawing a UML class diagram...? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?

[–] bestboyfriendintheworld@sh.itjust.works 2 points 19 hours ago* (last edited 19 hours ago) (1 children)

Yes, pretty much like UML diagrams. Who is responsible for allocating memory and freeing it.

Languages like Swift, Objective-C, C++ have features that mean you don’t need to do this by hand. But you have to tell the compiler if you want to keep and object around and who owns it.

See this article on Objective-C to see the different ways to manage memory this language supports.

[–] Ephera@lemmy.ml 1 points 7 hours ago

Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn't needed, to Rust where well-defined ownership is enforced by the language.

So, I wasn't aware that ownership is even as concrete of a thing in other languages...

[–] qaz@lemmy.world 6 points 3 days ago

It will become more complex when you start needing circular references in your datastructures.

[–] mholiv@lemmy.world 4 points 3 days ago

You’ll be fine. You will learn the lifetime stuff and all will work out. It’s not that bad to be honest.

[–] felsiq@lemmy.zip 2 points 3 days ago

Worse in the sense of more errors, sure, but as you go you’ll pick up more of the rust patterns of thinking and imo it’s very worth it. It’s an odd blend and can be a bit verbose but I definitely prefer it to a pure OO or pure functional style language personally