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

111–120 of 277 posts

Re: Announcing Rust 1.20

#111

Post by steveklabnik »

leshow wrote: post #107
kzrdude wrote: post #101

Earlier quoted context omitted.

Only that they are members of a trait, so you can use it in Rust's generic programming (bounded polymorphism).

is bounded another word for ad-hoc? I always considered Rust's polymorphism implementation like Haskell's, and AFAIK they call it ad hoc polymorphism.

IIRC, "bound" has more to do with quantification than polymorphism more generally.

There is "parametric" vs "ad-hoc". https://stackoverflow.com/questions/6730126/parametric-polym... has a link to the text of TAPL explaining the difference here.

Rust traits and Haskell typeclasses would be ad-hoc.

Re: Announcing Rust 1.20

#112

Post by saghm »

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…

Depending on the language, interfaces can be a lot less powerful than traits. Traits can have default implementations for some methods (meaning you don't have to explicitly implement all of them), and in some cases they can be completely derived automatically. They're really more similar to Haskell's typeclasses than traditionally OO interfaces.

Re: Announcing Rust 1.20

#113

Post by mikebenfield »

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…

> What? If you have instantiatable abstract data types with associated methods you have a "class". Calling them "structs" does not change that. There are classes defined with "struct" in C++ and D too.

So if I just take C's structs and add the ability to associate structs with functions using a "struct.function" notation, I now have classes? If so, a class isn't a very powerful concept, is it?

Here's an easy way to see the difference between traits and interfaces, and simultaneously see why some people find OOP completely inadequate for their purposes.

Imagine you're implementing several different types that all need to be able to be added. You've got integers, floats, mathematical vectors, and possibly other types. All of them should support an `add` method. But you should only be able add objects of the same type: an integer to an integer, a float to a float, and a vector to a vector. This incredibly simple idea, to my mind almost the simplest thing a person might want to do with a type system, cannot be expressed in most OOP languages using an interface with an `add` method.

But it can easily be expressed using traits (or using Haskell's type classes).

And this is why I never understood why anyone bothers with OOP.

Re: Announcing Rust 1.20

#114

Post by leshow »

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

Is-A does not and should not imply Inheritance. It merely implies polymorphism. I didn't get formally trained so I can't comment on what college/high school's teach but if they teach that Is-A relationships imply Inheritance then claiming Rust is OOP seems like a good way to educate the mis-educated regarding the difference.

What kind of polymorphism? Traditional OOP is subtype polymorphism. You can't really do that in Rust. It's main polymorphism is parametric and ad-hoc polymorphism a la Haskell. If that's considered OOP then OOP is so broad it's not a useful term

Re: Announcing Rust 1.20

#115

Post by lederhosen »

jeffdavis wrote: post #100
steveklabnik wrote: post #71

Earlier quoted context omitted.

> a weak reference inside a refcell, It'd likely be the other way, that is, you'd put a RefCell inside of an Rc/Weak. > it doesn't look like refcell works well with traits It should; I bet you had problems since you did it the other way around. > I'm a bit frustrated because this is so easy in C. You could do it the same way as you do it in C, if you're willing to resort to `unsafe`. FWIW, Rust sort of changes the eq…

Thank you. I will look into these and give it another try. It's a good point that maybe I should just have the right expectations here, and expect data structures to be hard in rust. I looked around a bit and it looks like these thing are quite challenging in haskell as well.

In Haskell it is easy, you can not create cyclic data structures ;-)

Re: Announcing Rust 1.20

#116

Post by leshow »

zaphar wrote: post #99
tree_of_item wrote: post #56

Earlier quoted context omitted.

> 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?

I'm not arguing this is a good thing. But I am saying that for the vast majority of programmers out there they use that pattern as a way of determining if they have those three attributes. It's cargo cult programming in a sense but it's also the only signal they've ever known.

I think calling Rust that would confuse people more than anything. They will look for their traditional inheritance style relationships and be frustrated that there is not really any support for it. Better to teach the features that Rust actually has, than to try and fit some uber generic definition of "Objects" that's not going to serve newcommers.

Re: Announcing Rust 1.20

#117

Post by kbenson »

steveklabnik wrote: post #62
_wmd wrote: post #61

What happened to the exhaustive list of unnamed Github contributors? I thought that was a really powerful marketing method: dear unnamed Github user x1230134384, your contribution has been acknowledged! Feedback without requiring identification, it's kindof very cool in a project like this.

If you click on the final link to thanks.rust-lang.org, you'll find it there! There have been talks about moving it back, but it's complicated. You can do the "duplicate it" strategy, but that has downsides. You could do an iframe, but then you're using an iframe. You could use JavaScript, but then a whole different crew of people will Get Mad.

Obviously the solution is to turn the thanks page into an API, add CORS headers, and then a bit of JS on the announce page to fetch the list from thanks.rust-lang.org and build the list on load or fall back to the current behavior.

Good luck determining whether I'm joking or not. I'm not even sure myself...

Re: Announcing Rust 1.20

#118

Post by hashmal »

kannanvijayan wrote: post #108
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Frankly, I'd just use unsafe pointers for the backrefs, and wrap the tree API up in a typesafe layer, and build on top of that. RefCells seem to add unnecessary redundancy here. You'll take a hit for runtime borrow for every pointer chase up the tree. If walking from a leaf to the root is important, you don't want to add an extra compare/branch/set to every pointer chase. Turns a single memory read into a branch, a w…

I'd take a similar approach. After all `unsafe` use cases include the implementation of data structures.

Re: Announcing Rust 1.20

#119

Post by msbarnett »

jeffdavis wrote: post #97
msbarnett wrote: post #74

Earlier quoted context omitted.

> I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once. The simple way to do that would be to allocate an array, and use indices into the array rather than pointers/references. Doing it with pointers isn't so much harder in Rust than C as it is that Rust is making you deal with how hard it is to get this right , whereas in C the c…

But in my example this is not hard to get right in C. The tree is constructed (on the stack would be fine), then used for a while without mutating it, then freed all at once. The thing that makes this hard in rust is destructors. If there's a cycle between A and B, and you destruct A first, then B, then B's destructor would see a dangling reference to A. And vice versa if you destruct B first. But I don't need destru…

> But in my example this is not hard to get right in C. The tree is constructed (on the stack would be fine), then used for a while without mutating it, then freed all at once.

It's still "hard to get right" in that at any time nothing is stopping you from violating any of the assumptions that make this "easy". It's never easy to write a solution that's "guaranteed to be safe" in C, but that's what you're trying to do by writing such a solution in Rust. To give but one example, nothing in C will stop your nodes from containing some resources which needs to be manually destructed and which get leaked when the stack frame is reclaimed.

Rust is going to require you to make those assumptions explicit, so that it can enforce them -- in this case, you need to explicitly restrict your solution to dealing with Copy types, which by construction don't implement Drop, and therefore have no destructors.

But at the end of the day, if all you want to do is swear to the compiler that you know what you're doing and you promise to not be stupid, wrap it in an unsafe and get C-style consequences if you got things wrong. You get C-Style easiness only by explicitly abandoning the attempt at guaranteeing safety for every type and scenario your solution could be used with.

Re: Announcing Rust 1.20

#120

Post by kbenson »

slavik81 wrote: post #89
GolDDranks wrote: post #30

Earlier quoted context omitted.

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`.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference: Rust: fn main() { let a: f32 = 1e7 + 0.5 + 0.5; let b: f32 = 1e7f32 + 0.5f32 + 0.5f32; println!("{}", a==c); // true } C: #include int main() { float a = 1e7 + 0.5 + 0.5; float b = 1e7f + 0.5f + 0.5f; printf("%s\n", a==b ? "true" : "false"); // false } That's awesome. I'm tot…

> While f might be a nicer suffice than f32, no suffix is even better.

Well, isn't float in C and C++ platform dependent, and just usually 4 bytes on common platforms? I like the idea of being explicit in the storage type, even if it's slightly more verbose.

Post reply on HN