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

121–130 of 277 posts

Re: Announcing Rust 1.20

#121

Post by hashmal »

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…

Quite often in Rust, the way to make it easier is to go one step back: instead of thinking about how to make a tree right, you might want to think about why you want a tree in the first place. Sometimes it's the right thing to do, sometimes there is another approach that fits Rust's paradigm better.

Speaking of paradigms, although Rust definitely looks "imperative", the ownership system makes it bloody different. Try to implement a tree "as in C" using Haskell or Prolog and you will lose time and energy for a result that does not use the language to its fullest.

Re: Announcing Rust 1.20

#122

Post by jeffdavis »

steveklabnik wrote: post #106
jeffdavis wrote: post #97

Earlier quoted context omitted.

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 I don't need destructors, or at least ones that can see these references, so it's frustrating. If you bound it so that it only accepts Copy types, then you can know there are no destructors.

Interesting. Then rust should not care about the destruction order, right?

Re: Announcing Rust 1.20

#123

Post by protomikron »

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…

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

I do not want to defend OOP, but I would like to add that object-orientated languages are often to be expected to support these 3 things (encapsulation, inheritance and polymorphism) - at least many sources list these properties as must-have to be considered object-orientated.

> This is the kind of argument that convinces me that OOP is completely bunk.

Agreed. E.g. functional programming has a sound foundation (λ-calculus), but in object-oriented land if often sounds a little bit hand-wavy.

Re: Announcing Rust 1.20

#124

Post by whyever »

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…

I think I would just put all the nodes into a Vec and use indices instead of references. This results in every node having the same lifetime, like you wanted. It is what the specialized graph libraries like petgraph are doing, and it is memory safe due to bound checks.

Re: Announcing Rust 1.20

#125

Post by stjepang »

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…

It's fairly easy to do this kind of thing using an arena and indices instead of pointers. Here's a simple splay tree with uplinks implemented this way:

https://github.com/stjepang/vec-arena/blob/master/examples/s...

Re: Announcing Rust 1.20

#126

Post by whyever »

msbarnett wrote: post #119
jeffdavis wrote: post #97

Earlier quoted context omitted.

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 d…

Nothing stops you from leaking memory in Rust either, it is considered memory safe, see std::mem::forget. Rust only safes you from use-after-free and double-free.

Re: Announcing Rust 1.20

#127

Post by tome »

lederhosen wrote: post #115
jeffdavis wrote: post #100

Earlier quoted context omitted.

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 ;-)

Huh? Sure you can.

Re: Announcing Rust 1.20

#128

Post by PopsiclePete »

jmcomets wrote: post #68
tomjakubowski wrote: post #40

Earlier quoted context omitted.

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

I used to be a huge fan of C++. I loved how you could work with a somewhat OO language while still wielding dark powers like: manual memory management, mix-n-match polymorphism (aka. virtual inheritance ), templates, type-erasing. Then I got a full time job working with a large C++ codebase. Since then I've been dealing with: - uninitialized variables / members - NULL checks - buffer overflows, especially with C-stri…

That's my main beef with C++. You read a book and it's beautiful - no uninitialized memory, safety, no C arrays/strings, RAII everywhere, it's clean, fast.....then you get to the "real world" and realize that 99% of C++ programmers are pretty f###ing horrible at their job and should've just stuck to naked C because at least then you'd be able to pin-point the bugs easier.

So C++ is a wonderful language - in a world that only exists in the creators' heads, or on committee tables, or on brand-new, post C++03 codebases. Basically - nowhere.

Re: Announcing Rust 1.20

#129

Post by smegel »

kibwen wrote: post #3

Interestingly, because Firefox chooses to use stable Rust exclusively, this is the version of Rust that will be used to deliver Quantum when Firefox 57 releases on November 14 (by which time Rust 1.21 will be out (releasing October 12), but Firefox 57 will be in beta by September 20).

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

Re: Announcing Rust 1.20

#130

Post by steveklabnik »

smegel wrote: post #129
kibwen wrote: post #3

Interestingly, because Firefox chooses to use stable Rust exclusively, this is the version of Rust that will be used to deliver Quantum when Firefox 57 releases on November 14 (by which time Rust 1.21 will be out (releasing October 12), but Firefox 57 will be in beta by September 20).

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

Rust doesn't have any more runtime than C, and also doesn't have a GC. Servo has bindings into SpiderMonkey's GC so that the JavaScript stuff works properly, but that's only that part.

That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. (I don't work on Firefox though so I could be wrong about some details.)

Post reply on HN