Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 277 posts

Re: Announcing Rust 1.20

#41

Post by zaphar »

steveklabnik wrote: post #28
zaphar wrote: post #23

Earlier quoted context omitted.

Obviously Rust is in the 4'th school which I like to call "The Rust School". All kidding aside, I think for any regular working day programmer Rust is obviously OOP. The debates are really just which parts of which favorite school of OOP you think Rust is inspired by. But what really matters is that Rust gives you: * Encapsulation * Polymorphism. * And Code Reuse. Which are the only three things anyone who reaches fo…

> Obviously Rust is in the 4'th school which I like to call "The Rust School". Ha! But yeah, if you're going to claim Rust is OOP, I would argue that makes the most sense. > what really matters is that Rust gives you: Right, this is the "Java School" definition. However, when people talk about OOP this way, when they say "polymorphism", they mean "subtype polymorphism" not "parametric polymorphism." Take https://docs…

Oh dear. That java tutorial just reads wrong to me but that's probably because I've been burned too many times by conflating polymorphism with code reuse in the form of inheritance.

I think the working programmer doesn't know or care though. They care about whether you can reuse code in some way. And whether you can substitute multiple implementations of an object act as one particular type.

The specifics of how you reach either of those goals is all they want to know and the pedantry that us language geeks love to engage in just blows right past them.

Re: Announcing Rust 1.20

#42

Post by copx »

steveklabnik wrote: post #7
copx wrote: post #2

"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed that the above wasn't in Rust to begin with, though. Can't think of any other languages which has classes but no class methods/variables.

I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book ( https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht... ) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit in…

Well, to me Rust code looks fundamentally like any other OO language e.g.

    let mut window: PistonWindow = WindowSettings::new(
            "piston: hello_world",
            [200, 200]
        )
        .exit_on_esc(true)
        .opengl(OpenGL::V2_1)
        .build()
        .unwrap();
If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP.

I think the Rust people just desperately try to disassociate themselves from the OOP label because OOP is not hip anymore. "So 90s" and all that.

I think that's childish. If you use a broad definition of OOP according to which C++, Smalltalk, Java, and Python are all OOP languages said definition certainly covers Rust too.

To be fair, even the C++ crowd doesn't like to use the term OOP anymore and instead say things like "generic programming".. but at the end of the day they too are instantiating classes.

Re: Announcing Rust 1.20

#43

Post by a_humean »

pcx wrote: post #29

Associated functions and associated constants sound so yum! That's one thing I would love to have in Flowtype. But classes seem to serve that use case well enough.

You get something similar to with static methods and properties on class definitions. In plain ES2017-ish class syntax:

class Test {

  static value = 1;

  static someStaticMethod = () => {
    return 5;
  }
}

console.log(Test.value) // 1

console.log(Test.someStaticMethod()) // 5

Edit: Sorry, this actually a Stage 3 TC39 feature. Not sure if you can use it with flowtype (I think you can), but you might be able to if you enable babel with stage-3 features:

https://github.com/tc39/proposal-class-fields

You don't actually need this fancy class syntax anyway. You can just define a class and then do:

Test.value = 5

Test.someStaticMethod = () => { return 5; }

The class stuff is just sugar over the prototype stuff anyway, and a class is just a constructor function object with a prototype chain.

Re: Announcing Rust 1.20

#44

Post by jandrese »

e12e wrote: post #17
jandrese wrote: post #4

Earlier quoted context omitted.

Now you have me wondering what use a class is without methods or variables. It's just a namespace?

Threadsafe (no externally visible mutable data) singleton instance?

Isn't all data (outside of unsafe blocks) in Rust already threadsafe? Isn't that one of the big selling points of the language?

Re: Announcing Rust 1.20

#45

Post by GolDDranks »

kibwen wrote: post #35
zaphar wrote: post #23

Earlier quoted context omitted.

Obviously Rust is in the 4'th school which I like to call "The Rust School". All kidding aside, I think for any regular working day programmer Rust is obviously OOP. The debates are really just which parts of which favorite school of OOP you think Rust is inspired by. But what really matters is that Rust gives you: * Encapsulation * Polymorphism. * And Code Reuse. Which are the only three things anyone who reaches fo…

I agree that it's better to focus on encapsulation/polymorphism/reuse, but the reason why I personally object to the idea that "for any regular working day programmer Rust is obviously OOP" is because inheritance is usually taught above all of these as the fundamental property of OOP. I doubt I'm the only one whose high school and college exposure to OOP was to model "Dog is-a Mammal, Cow is-a Mammal, Mammal is-a Ani…

Agree 100%. And I think that what is commonly thought of OOP (the Java model) suffers greatly from real-life analogies like that. Not everything fits into neat hierarchies – not in real life and not in code.

I also think that the concept of "class" suffers from a great amount of un-orthogonality. A class packages together a memory representation, an encapsulation boundary, an interface that defines functionality and a unit of type parametrisation. I find the way how Rust separates modules as the unit of encapsulation, traits as the unit of functionality and structs as the units of memory representation, very elegant.

Now if one could type-parametrise modules...

Re: Announcing Rust 1.20

#46

Post by steveklabnik »

zaphar wrote: post #41
steveklabnik wrote: post #28

Earlier quoted context omitted.

> Obviously Rust is in the 4'th school which I like to call "The Rust School". Ha! But yeah, if you're going to claim Rust is OOP, I would argue that makes the most sense. > what really matters is that Rust gives you: Right, this is the "Java School" definition. However, when people talk about OOP this way, when they say "polymorphism", they mean "subtype polymorphism" not "parametric polymorphism." Take https://docs…

Oh dear. That java tutorial just reads wrong to me but that's probably because I've been burned too many times by conflating polymorphism with code reuse in the form of inheritance. I think the working programmer doesn't know or care though. They care about whether you can reuse code in some way. And whether you can substitute multiple implementations of an object act as one particular type. The specifics of how you…

It's possible we've just interacted with different people; I've spoken to a lot that assume inheritance, specifically, and we get questions about it often.

Anyway, thanks for a good discussion!

Re: Announcing Rust 1.20

#47

Post by zaphar »

GolDDranks wrote: post #45
kibwen wrote: post #35

Earlier quoted context omitted.

I agree that it's better to focus on encapsulation/polymorphism/reuse, but the reason why I personally object to the idea that "for any regular working day programmer Rust is obviously OOP" is because inheritance is usually taught above all of these as the fundamental property of OOP. I doubt I'm the only one whose high school and college exposure to OOP was to model "Dog is-a Mammal, Cow is-a Mammal, Mammal is-a Ani…

Agree 100%. And I think that what is commonly thought of OOP (the Java model) suffers greatly from real-life analogies like that. Not everything fits into neat hierarchies – not in real life and not in code. I also think that the concept of "class" suffers from a great amount of un-orthogonality. A class packages together a memory representation, an encapsulation boundary, an interface that defines functionality and…

Ahhh the elegance of SML rears it's beautiful head :-)

Re: Announcing Rust 1.20

#48

Post by dbaupp »

copx wrote: post #42
steveklabnik wrote: post #7

Earlier quoted context omitted.

I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book ( https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht... ) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit in…

Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_world", [200, 200] ) .exit_on_esc(true) .opengl(OpenGL::V2_1) .build() .unwrap(); If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP. I thin…

> I think the Rust people just desperately try to disassociate themselves from the OOP label because OOP is not hip anymore.

No, it's mostly driven by the differing semantics despite happening to have similar syntax. Syntax is a surface polish that people focus on a lot, but doesn't drive the core language behaviour.

Re: Announcing Rust 1.20

#49

Post by steveklabnik »

copx wrote: post #42
steveklabnik wrote: post #7

Earlier quoted context omitted.

I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book ( https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht... ) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit in…

Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_world", [200, 200] ) .exit_on_esc(true) .opengl(OpenGL::V2_1) .build() .unwrap(); If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP. I thin…

> it would /could look fundamentally the same.

Yeah, the usage does, but the definition does not, the implementation does not, and the features are very different.

For example, "new" is just a convention here, not an actual constructor, as Rust does not have constructors.

> You create a window object and then call a bunch of its methods (mutating its state). That's OOP.

It depends on what you mean by "object". If structs are objects, then OOP boils down to only "you can use x.y() instead of y(x)", which I don't think is a good way to think about programming languages or their features. YMMV, of course.

> I think the Rust people just desperately

I can assure you, that's not the case for me at least; I love OOP languages enough to have both Ruby and Perl logos tattoo'd onto my body.

I don't like saying Rust is OOP because of said definitions elsewhere in the thread, as well as people struggling to map their OOP patterns over. If they hear "Rust is OOP", they expect to be able to do OOP-like things, and when they can't, that's a big frustration. Enough so that we had to add that book chapter.

Re: Announcing Rust 1.20

#50

Post by kibwen »

copx wrote: post #42
steveklabnik wrote: post #7

Earlier quoted context omitted.

I, at least, don't really think of Rust as having classes. Rusty design patterns don't really look like many traditional OOP design patterns. This is often a hurdle for new Rust programmers. Chapter 17 of the book ( https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht... ) is trying to grapple with this question. Part of the difficulty here is nailing down what "class" even means, exactly. Rust doesn't fit in…

Well, to me Rust code looks fundamentally like any other OO language e.g. let mut window: PistonWindow = WindowSettings::new( "piston: hello_world", [200, 200] ) .exit_on_esc(true) .opengl(OpenGL::V2_1) .build() .unwrap(); If you wrote that in C++ or Java or Python or.. it would /could look fundamentally the same. You create a window object and then call a bunch of its methods (mutating its state). That's OOP. I thin…

"OOP" has suffered since the 90s of being a somewhat vague term in practice (much to the chagrin of Smalltalkers), but making it even more overbroad just to make it apply to Rust will only drive the term further into uselessness. It's not about being "hip", it's about using terminology that's usefully precise. (For the record, I also think "functional programming" is a uselessly broad category these days, having become a victim of its own success.)

It's uncontroversial to state that Rust has methods, which are usually associated with OOP. It's also uncontroversial to state that Rust is utterly incapable of defining inheritance hierarchies, which are also usually associated with OOP. If we're going to argue about it, we might as well try to agree on terms that will let us say things that are meaningful.

Post reply on HN