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

21–30 of 277 posts

Re: Announcing Rust 1.20

#21

Post by dbaupp »

copx wrote: post #15
kibwen wrote: post #6

Earlier quoted context omitted.

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly s…

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

Having aggregate data types and syntactically having methods seems like a very facile definition of "OOP", versus the conventional uses referring to Smalltalk style message passing or inheritance and overrides. Other than being able to call functions as x.foo() rather than foo(x) or foo x or similar, languages like Haskell and C seem to satisfy the requirements for being OOP, which seems to make "OOP" completely useless as a category.

In any case, this point is been argued at length for every language, including Rust.

Re: Announcing Rust 1.20

#22

Post by slavik81 »

Is f32 the only suffix for float literals? That seems really noisy compared to just f in C. I'm mostly concerned about vector and matrix declarations, but even in the examples given, 1.0f32 / 0.0f32 looks like a mess of numbers compared to 1.f / 0.f;

Re: Announcing Rust 1.20

#23

Post by zaphar »

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…

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 for OOP is really looking for anyway. As fun as the PL theory discussions are. (Kind of a Hobby for me at least) I think those are the bits that actually matter to the people who truly need an answer to the question "Is Rust OOP or not?"

Re: Announcing Rust 1.20

#24

Post by vvanders »

copx wrote: post #15
kibwen wrote: post #6

Earlier quoted context omitted.

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly s…

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

Rust doesn't have inheritance which is one of the key pieces of OOP.

Traits just provide a single level of indirection and if you want to do anything more complex you'll need to use composition to achieve it.

Re: Announcing Rust 1.20

#25

Post by [deleted] »

copx wrote: post #15
kibwen wrote: post #6

Earlier quoted context omitted.

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly s…

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

[deleted]

Re: Announcing Rust 1.20

#26

Post by tatterdemalion »

sevensor wrote: post #18

Not a Rust programmer, so the answer to this question may be in TFM -- Rust has floats, but it doesn't make available constants for inf and NaN? Are you not guaranteed IEEE754 floats? const NAN: f32 = 0.0f32 / 0.0f32; const INFINITY: f32 = 1.0f32 / 0.0f32; Or is that just for the sake of example?

The consts are currently defined in modules with the same name as the type, `std::f32::NAN;`. This feature allows them to be associated with the type itself - `f32::NAN`. A small convenience.

Re: Announcing Rust 1.20

#27

Post by kibwen »

slavik81 wrote: post #22

Is f32 the only suffix for float literals? That seems really noisy compared to just f in C. I'm mostly concerned about vector and matrix declarations, but even in the examples given, 1.0f32 / 0.0f32 looks like a mess of numbers compared to 1.f / 0.f;

> Is f32 the only suffix for float literals?

Nope. `f32` is for single-precision floats, and `f64` is for double-precision floats. There have been some people lobbying for `f16` and `f128` as well.

Also, you don't need to use those suffixes. I imagine the OP is using them for maximum explicitness, but you can just write `1.0` and it will be inferred to a floating-point type as necessary (contrast `1`, which will be inferred to an integral type).

Re: Announcing Rust 1.20

#28

Post by steveklabnik »

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…

> 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.oracle.com/javase/tutorial/java/IandI/polymorph... as an example. Rust's only sub-typing is for lifetimes.

> As fun as the PL theory discussions are.

I definitely agree that in some senses, this is academic. But at the same time, practitioners can be mis-led by using terms in a different way than they're used to. This is sort of the argument I'm making above; since many practitioners see "polymorphism" as being equal to "subtype polymorphism", calling other types of polymorphism "polymorphism" is a more academic, less user-focused distinction.

Re: Announcing Rust 1.20

#29

Post by pcx »

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.

Re: Announcing Rust 1.20

#30

Post by GolDDranks »

slavik81 wrote: post #22

Is f32 the only suffix for float literals? That seems really noisy compared to just f in C. I'm mostly concerned about vector and matrix declarations, but even in the examples given, 1.0f32 / 0.0f32 looks like a mess of numbers compared to 1.f / 0.f;

Yes, it is, for 32-bit floats. However, most of the time you don't need to specify that, because it will be inferred from the context. (And if it isn't you can introduce hints like `let growth_rate: f32 = 50.0/140.0`) Also, Rust supports having _ anywhere in number literals. Some may argue that it makes things even noisier, but it helps to separate the suffix from the value itself: `100.0_f32`.
Post reply on HN