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

91–100 of 277 posts

Re: Announcing Rust 1.20

#91

Post by pjmlp »

kibwen wrote: post #35
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…

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…

That only happens when the teachers do a bad job not explaining interfaces, protocols, components, categories.... or as Rust puts them, traits.

Re: Announcing Rust 1.20

#92

Post by jeffdavis »

comex wrote: post #75
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. R…

Arenas have more to do with the allocation pattern, they don't solve the cycle problem, right?

Re: Announcing Rust 1.20

#94

Post by tatterdemalion »

kzrdude wrote: post #85
tatterdemalion wrote: post #26

Earlier quoted context omitted.

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.

It's more than a small convenience. It's a big feature that we can use when designing traits and APIs.

Yes of course (I work on Rust). I mean that the difference between f32::NAN and std::f32::NAN is a small convenience.

Re: Announcing Rust 1.20

#95

Post by steveklabnik »

skariel1 wrote: post #90
fish_fan wrote: post #81

Earlier quoted context omitted.

While it may be simpler, it also removes any safety that rust adds. I'd imagine you'd get more mileage out of just using pointers and unsafe blocks liberally to get lifetime checking where you can.

It is still safer than c, as it will not allow any segfaults. The only thing that can happen is a runtime error but no memory corruption so it is more akin to say Java or Go

The context of this thread is unsafe, which can segfault.

Re: Announcing Rust 1.20

#96

Post by steveklabnik »

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…

You often don't need it at all;

  fn foo(x: f32) { println!("{}", x); }

  fn main() {
      let x = 5.0;
      foo(x);
  }
It will look at the signature for foo, and infer that x must be f32.

Re: Announcing Rust 1.20

#97

Post by jeffdavis »

msbarnett wrote: post #74
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 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 destructors, or at least ones that can see these references, so it's frustrating.

Re: Announcing Rust 1.20

#99

Post by zaphar »

tree_of_item wrote: post #56
zaphar wrote: post #55

Earlier quoted context omitted.

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?

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.

Re: Announcing Rust 1.20

#100

Post by jeffdavis »

steveklabnik wrote: post #71
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 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.

Post reply on HN