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

71–80 of 277 posts

Re: Announcing Rust 1.20

#71

Post by steveklabnik »

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…

> 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 equation for what's easy here; thread-safe concurrency? Simple! Data structures? Hard! C is the other way around. So feeling a bit frustrated is normal; your C skills won't carry over, but it feels like they should.

> I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once

This sounds like an arena to me, which is another option, for sure.

If you post to https://users.rust-lang.org/, someone might be willing to whip up an example, or if you post your in-progress stuff, someone might be able to fix it for you.

https://crates.io/crates/petgraph might also just already have what you need, maybe.

Re: Announcing Rust 1.20

#72

Post by jandrese »

wahern wrote: post #60
jandrese wrote: post #44

Earlier quoted context omitted.

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…

I get that all bets are off once an unsafe() block is in play, but in the intended use case it seems like it should be safe.

Re: Announcing Rust 1.20

#73

Post by chancancode »

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…

Have you read "Learning Rust With Entirely Too Many Linked Lists"[1]? I think it will be quite helpful for these kind of situations. It walks you through all the possible tools in the language that is available to you, and at the end, if you just want to write it how you would in C, you could always do it "unsafely" with raw pointers (which is no worse than C).

---

[1] http://cglab.ca/~abeinges/blah/too-many-lists/book/

Re: Announcing Rust 1.20

#74

Post by msbarnett »

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 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 compiler is happy to let you think it's easy while you accidentally shoot yourself in the foot.

If you want the Rust compiler to accept your mistakes, you can always wrap it in an unsafe block ;)

Re: Announcing Rust 1.20

#75

Post by comex »

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…

Regarding traits: you can have Rc (by casting from Rc), but not RefCell. The reason is that Rc is a pointer, so the size of Rc can be constant regardless of the size of the type implementing the trait. But if you actually want a weak reference inside a refcell (as opposed to the other way around), RefCell> should work fine. Also consider the Cell type, which has a more limited API than RefCell but zero overhead.

Regarding everything being destructed at once: that’s called an arena, and there are crates for it:

https://crates.io/crates/typed-arena

Re: Announcing Rust 1.20

#76

Post by kibwen »

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.

I don't think that "is-a" is formally defined anywhere. In my school experience, using Java specifically, "is-a" was used to teach the `extends` keyword, while "has-a" was used to teach the `implements` keyword.

Re: Announcing Rust 1.20

#77

Post by evincarofautumn »

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…

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past.

So that[2] sounds wrong:

    This[3] probably screwed you up.
The somewhat confusing thing is that “this” is also used for the present or recent past, especially in more formal writing.

[1]: https://en.wikipedia.org/wiki/Deixis#Discourse

[2]: The following example

[3]: The previous sentence

Re: Announcing Rust 1.20

#78

Post by kibwen »

jandrese wrote: post #72
wahern wrote: post #60

Earlier quoted context omitted.

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…

I get that all bets are off once an unsafe() block is in play, but in the intended use case it seems like it should be safe.

You are correct there. Though we can quibble over the definition of "thread safety", concurrent memory safety is a subset of memory safety, which safe Rust enforces (or at least intends to enforce, modulo bugs).

Re: Announcing Rust 1.20

#79

Post by kibwen »

copx wrote: post #66
kibwen wrote: post #50

Earlier quoted context omitted.

"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 beco…

It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases. Declaring class inheritance to be the defining feature of OOP just because it was fundamental to 1990s Java courses makes about as much sense as to say extreme late-binding is a fundamental aspect of OOP, like Alan Kay does, and thus neither Java nor C++ are OOP languages. Yippee! Suddenly they are no…

> It actually is the consensus in the OOP world these days that composition is preferable to inheritance in most cases.

No argument there. :)

> Yet I dare to argue that this broad definition is not "useless" because both Erlang and Haskell default to immutable data and pure functions, and that defines FP more than anything.

I think this illustrates what I'm trying to get at: if one's task is to further the tenets of functional programming, then going around espousing "functional programming" as a general concept is less direct than just cutting to the chase and evangelizing for immutability and/or purity directly, especially when one considers that e.g. Common Lisp is neither immutable nor pure, but will be what plenty of people's minds jump to when they think of FP.

Re: Announcing Rust 1.20

#80

Post by JoshTriplett »

evincarofautumn wrote: post #77
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…

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past. So that[2] sounds wrong: This[3] probably screwed you up. The somewhat confusing thing is that “this” is also used fo…

> English is unusual in that it generally uses “this” for the future and “that” for the past.

I don't know that I'd describe it as "future" and "past"; it's more that English uses "this" for "current" and "that" for "other", whether past or future.

For instance, "this situation is broken, that solution looks promising" uses "this" to refer to the present and "that" for the future.

Post reply on HN