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

51–60 of 277 posts

Re: Announcing Rust 1.20

#51

Post by trapperkeeper74 »

tomjakubowski wrote: post #40
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.

> Rust keeps approaching C++'s feature set.. If there's one thing we C++ programmers can agree on, it's that having tons of features makes C++ a pleasure to work with... ?

Maybe by "pleasure" they mean "obscurity, gotchas and complexity are pleasurable because they trip up newbies and lend themselves to job security."

Re: Announcing Rust 1.20

#52

Post by zaphar »

steveklabnik wrote: post #46
zaphar wrote: post #41

Earlier quoted context omitted.

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!

It's highly possible. I almost never get to work with people who geek out over language theory :-D

I have to come to HN for that instead.

Re: Announcing Rust 1.20

#53

Post by tree_of_item »

zaphar wrote: post #23
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…

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…

> Encapsulation, Polymorphism, And Code Reuse.

These are three incredibly vague terms that pretty much every programming language can be said to provide. I can't understand how you think OOP is defined by this.

Do you think Haskell programmers are unable to reuse code? That they don't have any form of polymorphism? That they can't hide implementation details of functions, data structures and modules?

This is the kind of argument that convinces me that OOP is completely bunk. Its adherents can't even explain what it is!

Re: Announcing Rust 1.20

#54

Post by coldtea »

steveklabnik wrote: post #14
kbenson wrote: post #13

> An unstable sort could provide this result, but could also give this answer too: It might just be me, but using "this" twice in the same sentence to refer to two distinct items, one a prior example and one an upcoming example, is somewhat odd. That said, I understood it perfectly fine, it just caused me to stop and ponder the wording for a moment. The following might be more clear: An unstable sort could provide th…

Sounds great, I've made the change. Thanks! https://github.com/rust-lang/blog.rust-lang.org/commit/92031...

Well, while you're at it, "also" and "too" perform the same role there. So that phrase could be shortened to "but it could also give this answer".

Re: Announcing Rust 1.20

#55

Post by zaphar »

tree_of_item wrote: post #53
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…

> Encapsulation, Polymorphism, And Code Reuse. These are three incredibly vague terms that pretty much every programming language can be said to provide. I can't understand how you think OOP is defined by this. Do you think Haskell programmers are unable to reuse code? That they don't have any form of polymorphism? That they can't hide implementation details of functions, data structures and modules? This is the kind…

I wouldn't call myself an adherent. If anything I'm an adherent to the idea that Objects are just another Closure and vice versa. The interesting distinctions are in how they achieve those same goals.

But most working programmers don't care about the debate at all in my experience. When they say they are looking for an object oriented language what they are really saying is:

    I am looking for a language that has a syntax where you
    can declare an object and call methods on that object 
    usually with a dot but sometimes with an ->.
They don't actually care about much more than that most of the time.

Re: Announcing Rust 1.20

#56

Post by tree_of_item »

zaphar wrote: post #55
tree_of_item wrote: post #53

Earlier quoted context omitted.

> Encapsulation, Polymorphism, And Code Reuse. These are three incredibly vague terms that pretty much every programming language can be said to provide. I can't understand how you think OOP is defined by this. Do you think Haskell programmers are unable to reuse code? That they don't have any form of polymorphism? That they can't hide implementation details of functions, data structures and modules? This is the kind…

I wouldn't call myself an adherent. If anything I'm an adherent to the idea that Objects are just another Closure and vice versa. The interesting distinctions are in how they achieve those same goals. But most working programmers don't care about the debate at all in my experience. When they say they are looking for an object oriented language what they are really saying is: I am looking for a language that has a syn…

> I'm looking for a language with "objects" and a syntax like

But why? That's such a weird thing to look for. Clearly there's a reason they think they want "objects", but what is it? And why the focus on what syntax these objects have?

Re: Announcing Rust 1.20

#57

Post by naasking »

zaphar wrote: post #23
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…

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…

> Which are the only three things anyone who reaches for OOP is really looking for anyway.

Those are 3 characteristics of modularity, not object or class-specific in any meaningful sense. Rust isn't really a classic object-oriented language, but it is a modular language with object-like abstractions.

Re: Announcing Rust 1.20

#58

Post by sidlls »

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…

Generic programming and Object Oriented programming may overlap in the margins but are different concepts.

Personally I like Rust's better. It feels more like a "better C with generics" than C++ is.

Re: Announcing Rust 1.20

#59

Post by pcx »

a_humean wrote: post #43
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…

Yeah, either way it is objects. Traits feel so much more flexible though; and more natural a layer over JS object-orientedness. It also makes it a pain that there are some important semantics missing while using classes in JS. Someitmes Java feels much better.

Re: Announcing Rust 1.20

#60

Post by wahern »

jandrese wrote: post #44
e12e wrote: post #17

Earlier quoted context omitted.

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?

Rust isn't inherently thread-safe; not like in the way Java is thread-safe because of how the JVM's memory model is defined.

Rust makes it really difficult to share mutable data. But once you do that, such as by smuggling a pointer _through_ an unsafe block, all bets are off, even for code outside an unsafe block.

Also, as with Java there will always be bugs in the compiler and runtime. Rust programs were susceptible to StackClash just as much as C applications.

No matter what language you use, if you minimize shared mutable data you'll minimize thread-safety issues.

Post reply on HN