8 ms·

in Rust, methods should be object safe

61 points by fanf2 2y ago

sshine 2y ago
I'll start off by disagreeing with the first sentence: > I think we should use “method”, in Rust Just don't. Object-oriented programming is a 1980s buzzword. Let's help industry catch up. I don't care if people call them functions or methods in daily speech. I even do that sometimes, depending on whom I'm talking to. But let's not make up a highly technical definition of what a Rust method is. Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word.
- alex_lav 2y ago
  > Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word. Isn't this just true of any word with increased specificity? Why call it a square when we already have rectangle? I'm not really seeing how understanding method vs. function is "highly technical". At least, not more technical than, I don't know, writing Rust code in the first place?
  - stouset 2y ago
    It’s just not a particularly useful distinction IMO. I have worked in C++, C#, Ruby, and Rust over the past 25 years of programming and outside of academic contexts I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method. In academic circles, there’s some meaningful distinctions to be made. In software engineering I’ve yet to find a place where having a very specific name mattered or reduced communication burden.
    - Marzepansion 2y ago
      This might be your experiences, but I've never worked with people who called member functions methods in C++. I've seen C# programmers who had never worked with C++ call them that, but in the C++ teams I can't recall an instance of that, even for multi lingual engineers Though I do tend to work with teams where the average age is higher than the industry average, that might be warping my anecdotal experiences I have had situations where the distinction matters, and they aren't academic either, but in API design, especially for libraries
      - stouset 2y ago
        I’ve had a similar experience, but if someone called a method a function or vice versa, it’s never been unclear what they meant. And it’s never been something that people would have felt the need to correct someone on. I am aware of the distinction and I (probably?) instinctively use the two terms “correctly” the majority of the time. But if I just picked one or the other and used that word 100% of the time I would wager there would be zero confusion, except amongst pedants. For what it’s worth, I say this as an avowed pedant.
    - alex_lav 2y ago
      > I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method Because _you_ haven’t means the entire industry is wrong?
      - stouset 2y ago
        I’m not saying the industry is wrong. The two words have clear and distinct meaning. My point is only that fretting over the distinction between the words serves nearly zero utility in day to day software engineering. It’s like “less than” vs. “fewer”. Each has a correct use, but nobody is confused when you use the wrong one. Many confuse the two, to the point that it’s becoming less and less wrong to use one when the other should be used. “Method” and “function” are similar. In twenty years, nobody is going to care that they once had a distinctive purpose because that distinction serves little utility.
        alex_lav 2y ago
        “People will know what I mean, so why bother being correct or specific” is a flimsy argument, to me, as to why a person shouldn’t care about using correct and precise language. Nor does it really challenge the need for correct and precise language in the first place. Small children say things incorrectly and we still understand them. Should we all talk like that?
        stouset 2y ago
        Language is fluid and changes over time. Pedantically clinging to distinctions that no longer serve useful purposes doesn’t stop this from happening. If a clear separation in meaning between the two words was useful, their distinct use would become more closely adhered to over time. If not, people will start to blend and confuse the two. Of those options, the latter has happened and will likely continue happening with or without your objections. That this has happened is pretty clear evidence that the distinction hasn’t been worth maintaining. > Small children say things incorrectly and we still understand them. Should we all talk like that? Fully grown, articulate adults say things “incorrectly” all the time and nobody bats an eye. The sentence “Hey, where you going?” is missing an entire verb and every one of us has said and heard that sentence (or one like it) hundreds of times without anyone noticing or caring.
    - mcculley 2y ago
      I write Java daily. I find a lot of value in marking functions as static to make clear that they are not methods. There is a lot less cognitive overhead wondering if they only operate on their arguments or if they drag in their closure and the rest of the universe.
- verandaguy 2y ago
  Rust-specific nomenclature aside, I think it's useful in technical discussions to distinguish between (object) methods, class methods, and functions if your working language supports any combination of the three. The word "method" is baked into the official Rust docs[0], and while I personally find the definition in the docs to be satisfying, I don't think the author's argument for narrowing that definition down is unreasonable or (more importantly) unworthy of discussion. [0] https://doc.rust-lang.org/rust-by-example/fn/methods.html
- humanfromearth9 2y ago
  [dead]
zamalek 2y ago
Author is correct that Rust is not OOP. It simply has optional dispatch (which does not an OOP language make). I'm sure many of my fellow rustaceans will agree that the lack of OOP is one of the most competitive features of Rust.
- pjmlp 2y ago
  Only those that never picked a Computer Science book on OOP type systems.
  - zamalek 2y ago
    Adhod. I have 18 years of professional experience with OOP, all of it a bloody waste of time. Exhibit: https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC
    - pjmlp 2y ago
      Apparently not enough to actually understand OOP type theory.
      - Ygg2 2y ago
        No one that claims to know what OOP is, knows what it means. Because the term is loose and hard to pin down. If OOP encompasses both Smalltalk AND Rust, it's like saying your definition of X includes a neutron star and giraffe. By OOP type theory, you mean category theory? ---- Most what people recognize as OOP today is just Class/Inheritance oriented programming, and Rust doesn't belong in that camp, trying to use structural patterns from that kind of OOP in Rust is often a recipe for disaster.
        pjmlp 2y ago
        Not at all, OOP type theory is OOP type theory. Not what most people on the street think OOP is all, with their anti-Java bias, rather the Computer Science studies of type systems and their application across all forms of OOP in all programming languages ever invented. Rust has enough features from OOP type systems, regardless of the anti-OOP feeling trying to pretend it doesn't. Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there.
Karellen 2y ago
// counter_associated.rs [...] let c = Counter::increment(f); What is `f` here?
- jph 2y ago
  Just a typo. It's meant to be `c` which is defined on the previous line.
  - tialaramex 2y ago
    This is a strong reason to, either: Write your examples as Compiler Explorer links (or to some other playground tech, Rust has one to itself but it's easier to remember rust.godbolt.org) so you can see when your example doesn't work Or, write in Markdown and use tooling to perform tests the same way Rustdoc does, if you wrote what claims to be code, just scoop it up and execute it, if it doesn't compile then we find out before we publish. I'd say 80% of the time when I write more than one or two lines I write a bug, often it's a minor typo that the compiler would catch but sometimes it's a larger mistake and means I should re-evaluate my entire premise.
karma_pharmer 2y ago
"Object-safe" really ought to be called "dyn-safe".
thecodedmessage 2y ago
The word “method” already has a definition in Rust, which includes all intrinsic and trait methods. I feel like ‘dyn’ is relatively rarely useful and defining the term “method” based on what’s compatible with it is a bad idea.
palata 2y ago
It is a nice read! I am not super familiar with the definition of "object-safe" (I read the docs but the definition is not completely trivial for me). Does it work to say that an "object-safe" method mutates the object? That's what happens when you take `&mut self`, right? But if I understood this correctly, I guess it means that a function without side-effect in Java should not really count as a method? Because in Java I call it a method whether it has a side-effect or not. Which corresponds exactly to the definition of `method` in the Rust docs, I think [1]. In C++, I would think that this is the difference between a const (no side-effect) and a non-const (side-effect) method. [1]: https://doc.rust-lang.org/reference/items/associated-items.html#associated-functions-and-methods https://doc.rust-lang.org/reference/items/associated-items.h...
- throwup238 2y ago
  It has to do with type erasure and knowing how big a type is in memory, not mutation. With traits, you can erase the implementing type and get back a vtable of a trait's method - called a trait object. A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T). Once it's a trait object, T is no longer known and the compiler doesn't know how much memory to allocate on the stack or heap, which makes it impossible to use. That's why trait objects have to be boxed or behind references - all pointers have a known size.
  - diarrhea 2y ago
    > A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T) That, and much more: https://doc.rust-lang.org/reference/items/traits.html#object-safety https://doc.rust-lang.org/reference/items/traits.html#object... .
  - asa400 2y ago
    This is the shortest, clearest explanation I've yet seen of object safety. Thanks.
- steveklabnik 2y ago
  Not every trait can be made into a trait object. Traits that are "object safe" can be made into a trait object. Nothing to do with mutation, or side effects.
justincredible 2y ago
[dead]
bfrog 2y ago
People coming to rust attempting to apply typical OOP terms and patterns are likely to hit walls quickly. There’s are some things that of course look familiar. But it’s not where Rust came from, and it’s not what Rust provides.
dangmale 2y ago
[flagged]
dangmale 2y ago
[dead]
- Ygg2 2y ago
  It's not "I have no clue". It's about what do you mean by "clue", i.e. semantics discussion. I'm trying to figure out what does pjmlp really means by OOP. From what I've seen, it's basically a checklist of features, and the more features you check out, the more OOP you are. What I've learned in uni was basically languages derived from Simula/Smalltalk lineage. If you presume for a moment, pjmlp is 100% in right. Then it's difficult to find a language that isn't OOP. What is the informational contents in saying well C is OOP, Java is OOP, and Rust is OOP? I mean, you could with a straight face claim that Assembly is OOP, since it has some ad-hoc polymorphism. Why is this important? If the informational content of a statement is low, "language is OOP" approaches the value of "language is language". An utterly useless statement. You can say the sky is blue - that's a useful statement, based on that you can predict sunny weather. Or "sky is red" again useful, you can predict it's probably sunset. But if you say "sky is in one of visible colors", that's useless. Is this really different from other language paradigms? I can quickly identify and recognize a structural vs non-structural language (presence of if/else/while, lack of dedicated GOTOs). But because the OOP property of language is so nebulous, it's difficult to identify it. And knowing something is OOP doesn't help you. ---- It's in my opinion, much better to look at what languages can do or can't do. With that in hand, you start to see how Rust OOP is nothing like Java/C#. And how C OOP is nothing like Rust or Java OOP. Want to implement DOM in Rust? You're going to have a terrible time because it depends on the presence of some kind of inheritance mechanism. And that's very useful for a programmer because it's information you can use for reasoning.
  - neonsunset 2y ago
    C# is way more similar to Rust than Java, please do not bundle it together: proper generics, async, iterator expressions, trait composition (through interfaces), extension methods, higher order functions, low-level control with `unsafe` syntax when necessary, slice types.
    - 2y ago

61 points by fanf2 2y ago

I'll start off by disagreeing with the first sentence: > I think we should use “method”, in Rust Just don't. Object-oriented programming is a 1980s buzzword. Let's help industry catch up. I don't care if people call them functions or methods in daily speech. I even do that sometimes, depending on whom I'm talking to. But let's not make up a highly technical definition of what a Rust method is. Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word.

alex_lav 2y ago
> Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word. Isn't this just true of any word with increased specificity? Why call it a square when we already have rectangle? I'm not really seeing how understanding method vs. function is "highly technical". At least, not more technical than, I don't know, writing Rust code in the first place?
- stouset 2y ago
  It’s just not a particularly useful distinction IMO. I have worked in C++, C#, Ruby, and Rust over the past 25 years of programming and outside of academic contexts I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method. In academic circles, there’s some meaningful distinctions to be made. In software engineering I’ve yet to find a place where having a very specific name mattered or reduced communication burden.
  - Marzepansion 2y ago
    This might be your experiences, but I've never worked with people who called member functions methods in C++. I've seen C# programmers who had never worked with C++ call them that, but in the C++ teams I can't recall an instance of that, even for multi lingual engineers Though I do tend to work with teams where the average age is higher than the industry average, that might be warping my anecdotal experiences I have had situations where the distinction matters, and they aren't academic either, but in API design, especially for libraries
    - stouset 2y ago
      I’ve had a similar experience, but if someone called a method a function or vice versa, it’s never been unclear what they meant. And it’s never been something that people would have felt the need to correct someone on. I am aware of the distinction and I (probably?) instinctively use the two terms “correctly” the majority of the time. But if I just picked one or the other and used that word 100% of the time I would wager there would be zero confusion, except amongst pedants. For what it’s worth, I say this as an avowed pedant.
  - alex_lav 2y ago
    > I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method Because _you_ haven’t means the entire industry is wrong?
    - stouset 2y ago
      I’m not saying the industry is wrong. The two words have clear and distinct meaning. My point is only that fretting over the distinction between the words serves nearly zero utility in day to day software engineering. It’s like “less than” vs. “fewer”. Each has a correct use, but nobody is confused when you use the wrong one. Many confuse the two, to the point that it’s becoming less and less wrong to use one when the other should be used. “Method” and “function” are similar. In twenty years, nobody is going to care that they once had a distinctive purpose because that distinction serves little utility.
      - alex_lav 2y ago
        “People will know what I mean, so why bother being correct or specific” is a flimsy argument, to me, as to why a person shouldn’t care about using correct and precise language. Nor does it really challenge the need for correct and precise language in the first place. Small children say things incorrectly and we still understand them. Should we all talk like that?
        stouset 2y ago
        Language is fluid and changes over time. Pedantically clinging to distinctions that no longer serve useful purposes doesn’t stop this from happening. If a clear separation in meaning between the two words was useful, their distinct use would become more closely adhered to over time. If not, people will start to blend and confuse the two. Of those options, the latter has happened and will likely continue happening with or without your objections. That this has happened is pretty clear evidence that the distinction hasn’t been worth maintaining. > Small children say things incorrectly and we still understand them. Should we all talk like that? Fully grown, articulate adults say things “incorrectly” all the time and nobody bats an eye. The sentence “Hey, where you going?” is missing an entire verb and every one of us has said and heard that sentence (or one like it) hundreds of times without anyone noticing or caring.
  - mcculley 2y ago
    I write Java daily. I find a lot of value in marking functions as static to make clear that they are not methods. There is a lot less cognitive overhead wondering if they only operate on their arguments or if they drag in their closure and the rest of the universe.
verandaguy 2y ago
Rust-specific nomenclature aside, I think it's useful in technical discussions to distinguish between (object) methods, class methods, and functions if your working language supports any combination of the three. The word "method" is baked into the official Rust docs[0], and while I personally find the definition in the docs to be satisfying, I don't think the author's argument for narrowing that definition down is unreasonable or (more importantly) unworthy of discussion. [0] https://doc.rust-lang.org/rust-by-example/fn/methods.html
humanfromearth9 2y ago
[dead]

zamalek 2y ago

Author is correct that Rust is not OOP. It simply has optional dispatch (which does not an OOP language make). I'm sure many of my fellow rustaceans will agree that the lack of OOP is one of the most competitive features of Rust.

pjmlp 2y ago
Only those that never picked a Computer Science book on OOP type systems.
- zamalek 2y ago
  Adhod. I have 18 years of professional experience with OOP, all of it a bloody waste of time. Exhibit: https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC
  - pjmlp 2y ago
    Apparently not enough to actually understand OOP type theory.
    - Ygg2 2y ago
      No one that claims to know what OOP is, knows what it means. Because the term is loose and hard to pin down. If OOP encompasses both Smalltalk AND Rust, it's like saying your definition of X includes a neutron star and giraffe. By OOP type theory, you mean category theory? ---- Most what people recognize as OOP today is just Class/Inheritance oriented programming, and Rust doesn't belong in that camp, trying to use structural patterns from that kind of OOP in Rust is often a recipe for disaster.
      - pjmlp 2y ago
        Not at all, OOP type theory is OOP type theory. Not what most people on the street think OOP is all, with their anti-Java bias, rather the Computer Science studies of type systems and their application across all forms of OOP in all programming languages ever invented. Rust has enough features from OOP type systems, regardless of the anti-OOP feeling trying to pretend it doesn't. Static and dynamic polymorphism, methods, data encapsulation, type dispatch, all there.

Karellen 2y ago

// counter_associated.rs [...] let c = Counter::increment(f); What is `f` here?

jph 2y ago
Just a typo. It's meant to be `c` which is defined on the previous line.
- tialaramex 2y ago
  This is a strong reason to, either: Write your examples as Compiler Explorer links (or to some other playground tech, Rust has one to itself but it's easier to remember rust.godbolt.org) so you can see when your example doesn't work Or, write in Markdown and use tooling to perform tests the same way Rustdoc does, if you wrote what claims to be code, just scoop it up and execute it, if it doesn't compile then we find out before we publish. I'd say 80% of the time when I write more than one or two lines I write a bug, often it's a minor typo that the compiler would catch but sometimes it's a larger mistake and means I should re-evaluate my entire premise.

karma_pharmer 2y ago

"Object-safe" really ought to be called "dyn-safe".

thecodedmessage 2y ago

The word “method” already has a definition in Rust, which includes all intrinsic and trait methods. I feel like ‘dyn’ is relatively rarely useful and defining the term “method” based on what’s compatible with it is a bad idea.

palata 2y ago

It is a nice read! I am not super familiar with the definition of "object-safe" (I read the docs but the definition is not completely trivial for me). Does it work to say that an "object-safe" method mutates the object? That's what happens when you take `&mut self`, right? But if I understood this correctly, I guess it means that a function without side-effect in Java should not really count as a method? Because in Java I call it a method whether it has a side-effect or not. Which corresponds exactly to the definition of `method` in the Rust docs, I think [1]. In C++, I would think that this is the difference between a const (no side-effect) and a non-const (side-effect) method. [1]: https://doc.rust-lang.org/reference/items/associated-items.html#associated-functions-and-methods https://doc.rust-lang.org/reference/items/associated-items.h...

throwup238 2y ago
It has to do with type erasure and knowing how big a type is in memory, not mutation. With traits, you can erase the implementing type and get back a vtable of a trait's method - called a trait object. A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T). Once it's a trait object, T is no longer known and the compiler doesn't know how much memory to allocate on the stack or heap, which makes it impossible to use. That's why trait objects have to be boxed or behind references - all pointers have a known size.
- diarrhea 2y ago
  > A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T) That, and much more: https://doc.rust-lang.org/reference/items/traits.html#object-safety https://doc.rust-lang.org/reference/items/traits.html#object... .
- asa400 2y ago
  This is the shortest, clearest explanation I've yet seen of object safety. Thanks.
steveklabnik 2y ago
Not every trait can be made into a trait object. Traits that are "object safe" can be made into a trait object. Nothing to do with mutation, or side effects.

justincredible 2y ago

[dead]

bfrog 2y ago

People coming to rust attempting to apply typical OOP terms and patterns are likely to hit walls quickly. There’s are some things that of course look familiar. But it’s not where Rust came from, and it’s not what Rust provides.

dangmale 2y ago

[flagged]

dangmale 2y ago

[dead]

Ygg2 2y ago
It's not "I have no clue". It's about what do you mean by "clue", i.e. semantics discussion. I'm trying to figure out what does pjmlp really means by OOP. From what I've seen, it's basically a checklist of features, and the more features you check out, the more OOP you are. What I've learned in uni was basically languages derived from Simula/Smalltalk lineage. If you presume for a moment, pjmlp is 100% in right. Then it's difficult to find a language that isn't OOP. What is the informational contents in saying well C is OOP, Java is OOP, and Rust is OOP? I mean, you could with a straight face claim that Assembly is OOP, since it has some ad-hoc polymorphism. Why is this important? If the informational content of a statement is low, "language is OOP" approaches the value of "language is language". An utterly useless statement. You can say the sky is blue - that's a useful statement, based on that you can predict sunny weather. Or "sky is red" again useful, you can predict it's probably sunset. But if you say "sky is in one of visible colors", that's useless. Is this really different from other language paradigms? I can quickly identify and recognize a structural vs non-structural language (presence of if/else/while, lack of dedicated GOTOs). But because the OOP property of language is so nebulous, it's difficult to identify it. And knowing something is OOP doesn't help you. ---- It's in my opinion, much better to look at what languages can do or can't do. With that in hand, you start to see how Rust OOP is nothing like Java/C#. And how C OOP is nothing like Rust or Java OOP. Want to implement DOM in Rust? You're going to have a terrible time because it depends on the presence of some kind of inheritance mechanism. And that's very useful for a programmer because it's information you can use for reasoning.
- neonsunset 2y ago
  C# is way more similar to Rust than Java, please do not bundle it together: proper generics, async, iterator expressions, trait composition (through interfaces), extension methods, higher order functions, low-level control with `unsafe` syntax when necessary, slice types.
  - 2y ago