5 ms·

I mean it depends. Many of aspects of Rust that are perceived as sharp edges are in fact the programmer bringing in their preferences and paradigms from other l

• zozbot234 4y ago
  Rust actually supports most OOP features, with the main exception of implementation inheritance. And implementation inheritance is a nasty footgun in large-scale software systems (search around for: "fragile base class problem"), in a way that just doesn't apply to simple composition and pure interfaces (traits). So it's hard to fault Rust for including the latter and not the former.
  • hyperman1 4y ago
    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.
    • deleted 4y ago
      [deleted]
    • FpUser 4y ago
      >"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
      • atoav 4y ago
        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.
        • FpUser 4y ago
          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.
    • philosopher1234 4y ago
      > designs got better for it. What is better about them?
    • pimeys 4y ago
      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%2Fdatamodel%2Fparser-database https://github.com/prisma/prisma-engines/tree/main/libs%2Fda...
      • int_19h 4y ago
        How is this fundamentally different from raw pointers?
        • dralley 4y ago
          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.
          • int_19h 4y ago
            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".
    • pflanze 4y ago
      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?
  • captainmuon 4y ago
    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.
    • pentachoron 4y ago
      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?
    • nicoburns 4y ago
      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)
      • pjmlp 4y ago
        It is no different than using interfaces, protocols, pure virtual base classes....
        • dllthomas 4y ago
          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.
  • pizza234 4y ago
    > 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).
    • zozbot234 4y ago
      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.
    • glandium 4y ago
      You can define a field with the type of the base class in the subclass, and impl Deref for SubClass, with Target = BaseClass.
      • cylon13 4y ago
        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.
    • grey-area 4y ago
      Does OOP require inheritance?
  • Ygg2 4y ago
    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.
    • pjmlp 4y ago
      Yes it does, OOP is a spectrum not "like Java does it".
      • Ygg2 4y ago
        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.
        • ModernMech 4y ago
          To me, OOP always meant passing messages to objects, but it seems everyone has their own definition depending on experience.
        • pjmlp 4y ago
          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 https://github.com/pjmlp/RaytracingWeekend-Rust
          • Ygg2 4y ago
            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.
  • intelijstupide 4y ago
    > 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.
• hurril 4y ago
  This sounds to me like the journey into functional programming. I've experienced the same thing myself.
  • AndrewDucker 4y ago
    I've encountered this pretty-much every time that I've learned a new language or framework. I start out trying to use it the way I've used things before, and then I slowly learn how the people who wrote it expect me to work, and then things get a lot easier.
    • hurril 4y ago
      That too and I don't think I'm even done with that, myself :) What I meant is the step away from the notion that things are objects, stuff gets done with methods, methods are available via mixins/ inheritance/ magic, etc. I've seen the notion of using values and pure functions as data oriented programming recently but never understood what that moniker adds.
      • AndrewDucker 4y ago
        I think that going with pure functions/functional programming simplifies things, because it makes it much easier to test that things work as you'd expect when you don't have side-effects/state to think about.
• dotancohen 4y ago
  As someone who even structures their Python in OOP, I'd appreciate elaboration on how you organize your Rust code. I've been glancing at Rust for far too long, never finding a weekend to dive in. Save me some headaches, how should I approach e.g. Customer - Product - Order relations without OOP? What is the canonical "Rust Way"?
  • nicoburns 4y ago
    Your customer, product and order are still going to be objects, but they won’t reference each other directly with references/pointers. Instead they’ll either store an id, or you’ll have a central registry of relationships using some kind of id (could be a key into a hashmap or an index into a vector) and then fetch data from the central store (or have the caller pass it in) at the last minute when running code that does something.
    • dralley 4y ago
      The nice thing about doing it this way is that it makes it much easier to serialize and/or save to a database.
    • gary17the 4y ago
      > they won’t reference each other directly with references/pointers I'm not sure if I understood your reply correctly, but there seems to be nothing in Rust stopping one dynamic trait (interface-based) object directly referencing another dynamic trait (interface-based) object. The main difference between C++ O-O and Rust trait-oriented programming is C++ inheritance of implementation vs. Rust inheritance of interfaces. You can also downcast in Rust, if you try hard enough. https://gist.github.com/rust-play/fbe471b12a0fabe4ab7b653835251073 https://gist.github.com/rust-play/fbe471b12a0fabe4ab7b653835...
      • nicoburns 4y ago
        You can do references in Rust. But you can only have one mutable reference to an object at once unless you work around this with locks (Mutex, RefCell, etc). So for anything other than trivial child object references, you can quickly paint yourself into a corner of compilation errors by using webs of references. And this seems to be the basis of a lot of people's frustrations with Rust. It's true that you also can't do inheritance. But I've found this tends to be less of a problem as most OOP languages encourage composition over inheritance anyway, and composition works the same in Rust as in other languages.
• greenmana 4y ago
  Having studied mostly OOP/Java at the uni, and been using mostly C# at work, I realized I might actually start to find programming fun again through Go. I've studied it a bit recently and this idea of interfaces with composition over inheritance etc. made somehow a lot more sense to me, and gave me this boost to try and learn it more because it felt so enjoyable. Not even with some practical problem at hand to solve, but just on an abstract level, not having to deal with OOP classes and inheritance and all the things. Now I just need to find a Go job and get my feet a little more wet. ;P I'm talking about Go because it gives me similar feelings as Rust, but Rust I have a lot less experience with. I hope there's a similar fun and excitement to be found in Rust as well, after unlearning some old habits.
  • linuxftw 4y ago
    Go is fun at first, and then it becomes soul sucking. It's all boiler plate. Many large scale projects have a lack of adequate unit testing, so large code bases are particularly painful to maintain. I attribute this lack of tests due to how the code needs to be structured, you have to needlessly add 'interfaces' throughout your code to accomplish things. Go has it's strengths, but IMO fun isn't one of them. It turns into soul-suck quickly.
    • metaltyphoon 4y ago
      I'm in the same position as OP and was wondering the same thing; finding a job using Go. Is the bloat that you see the most related to error checking? If not what else is it?
      • ushakov 4y ago
        for me it's lack of map/reduce
      • linuxftw 4y ago
        The bloat is mostly related to mocking and making a fake client for everything for unit tests, and the practices you have to follow to make that actually work. In Python or Java, you can do something like: class: f1(): self.some_api_call() <process api call here> test_class extends class some_api_call(): <mock definition> In go, you cannot do this. Fair enough, but everyone writes object-style code because it's easier and there's less boiler plate. If you do this, you can't write tests. Instead, you have to do something like: class: apiMethod = nil f1(): self.apiMethod() <process api call> And assign apiMethod when you create the instance of the object; there are no constructors because they're not traditional objects, you need to create a factor method (boiler plate) or build the struct by hand (boiler plate). None of this is terribly challenging in and of itself, but if you work on large code bases, nobody did this because it's extra work, and now you have to refactor it because you want to make a change to the critical business logic and prove you're not introducing a regression (a constraint the l33t coders before you didn't have because they get to go fast and break things). And finally, often times the thing you need to mock is in someone else's package, and it doesn't implement an interface, or the thing you need to mutate is private, etc, etc. You end up need to mock half of a package sometimes. None of this is insurmountable, but when you do it day in and day out for years like I did, it's a real slog, and it sucks your soul out of your body. It wasn't uncommon for me to spend literally 20x as long refactoring and implementing tests as it was to ship features. If you look at some unit tests from large go projects, you'll see stuff like struct{struct{struct{struct{...}}},struct{struct{struct{...}}}} because so much stuff needs to be mocked up. And since interfaces are disjointed from classes, you won't know with certainty which methods you need to needlessly mock for your mock class until you try to compile, because the interface is defined somewhere else and not attached to a base class, it's just a definition floating out there in the source somewhere.