Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some notes on Rust

lambda-the-ultimate.org

Post reply on HN
Print view View original

61–70 of 113 posts

Re: Some notes on Rust

#61

Post by steveklabnik »

charlieflowers wrote: post #33
stebalien wrote: post #6

I don't have an account there so I'll comment here: > In particular, allocating a new object and returning a reference to it it from a function is common in C++ but difficult in Rust, because the function doing the allocation doesn't know the expected lifetime of what it returns. This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. Refere…

> References and lifetimes allow you to safely return pointers to stack allocated objects. In C++, you'd have to do this: MyType value; my_function(&value); When returning references, rust uses the lifetimes instead of explicit declarations to figure out where (on the stack) `value` needs to be allocated. OMG, thank you for including this. I spent several months reading every bit of documentation that was available f…

> But I don't know if technical details such as this are high enough on the priority list.

There are actual features which still have no documentation. It's hard being a single person trying to keep up with changes from tons of other people, many full time and some community. I may be the person who is most looking forward to Rust being stable...

Re: Some notes on Rust

#62

Post by falcolas »

pcwalton wrote: post #12
falcolas wrote: post #7

Earlier quoted context omitted.

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

> Except where they can't, and those locations aren't terribly consistent. Why aren't they consistent? The Rust type inference is generally very good, and the places where you have to annotate are places where any typechecker would force you to annotate, because the types are simply underconstrained (e.g. the return type of Vec::collect or mem::transmute). > The Rust designers have publicly announced their preference…

> Why aren't they consistent?

So, I went back to do a bit of research, and it's gotten better since this first bothered me, my apologies. My beef was with the `let x = vet::Vector::New::()` vs `let x: Vec = vec::Vec::New()`. Perhaps not the best way to word it, so consider this objection retracted. :)

> the idea that we intentionally made the type inference less powerful than it could have been is totally false

Except for function definitions, where the types could be inferred from the function bodies, but are not:

https://www.reddit.com/r/rust/comments/2bcof3/rust_type_infe...

Plus (and this is more related to the complete lack of implicit type conversions), there are types everywhere in the program. I frequently can't write a number without having to append a type, even when the type has been explicitly defined previously.

Here's one of my favorites from a recent attempt to write a ray tracer:

    let mut s: Vec3 = Vec3{x: 0f64, y: 0f64, z: 0f64, w: 0f64};

Re: Some notes on Rust

#63

Post by mkishi »

falcolas wrote: post #7
stebalien wrote: post #6

I don't have an account there so I'll comment here: > In particular, allocating a new object and returning a reference to it it from a function is common in C++ but difficult in Rust, because the function doing the allocation doesn't know the expected lifetime of what it returns. This is what boxes are for. A Box is a unique pointer to a value on the heap and can be used without knowing compile-time lifetimes. Refere…

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

> The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee.

Care to link/elaborate this? I thought the recommendation was to return by value in this case -- making it easy for the caller to decide where to store the value. The move semantics would then optimize the copy away, so you end up using either the caller's stack or the heap, depending on how the call was made.

Re: Some notes on Rust

#64

Post by NotableAlamode »

Animats wrote: post #58

Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html ) I wasn't expecting it to be picked up on Hacker…

Just a historical note: Rust's ownership system has much historical pedigree, such as the Cyclone language and the work on ML compilers with region inference, following Tofte and Talpin's pioneering work. The Wikipedia article (https://en.wikipedia.org/wiki/Region-based_memory_management...) has a good overview.

Re: Some notes on Rust

#65

Post by steveklabnik »

mkishi wrote: post #63
falcolas wrote: post #7

Earlier quoted context omitted.

> References and lifetimes allow you to safely return pointers to stack allocated objects. This is explicitly called out as non-idiomatic behavior in the documentation, however. The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. In fact, in general it's recommended not to use Box, because it complicates human reasoning about the code. And while it gets around a l…

> The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. Care to link/elaborate this? I thought the recommendation was to return by value in this case -- making it easy for the caller to decide where to store the value. The move semantics would then optimize the copy away, so you end up using either the caller's stack or the heap, depending on how the call was made.

You're correct.

Re: Some notes on Rust

#66

Post by lmm »

pjmlp wrote: post #16
Q6T46nT668w6i3m wrote: post #8

> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-ti…

Only if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.

C++14 may be a bit new for some circumstances - but surely it's more mature than Rust (and is likely to retain that advantage).

Re: Some notes on Rust

#67

Post by mkishi »

steveklabnik wrote: post #65
mkishi wrote: post #63

Earlier quoted context omitted.

> The preferred action is to allocate on the caller's heap and pass a mutable reference down to the callee. Care to link/elaborate this? I thought the recommendation was to return by value in this case -- making it easy for the caller to decide where to store the value. The move semantics would then optimize the copy away, so you end up using either the caller's stack or the heap, depending on how the call was made.

You're correct.

Actually, I got curious and tried it out. Turns out Rust didn't optimize the heap case: it used the caller's stack, and only then copied the value to the heap.

https://play.rust-lang.org/?code=%23!%5Bfeature(core)%5D%0A%...

Re: Some notes on Rust

#68

Post by aaron_m04 »

steveklabnik wrote: post #61
charlieflowers wrote: post #33

Earlier quoted context omitted.

> References and lifetimes allow you to safely return pointers to stack allocated objects. In C++, you'd have to do this: MyType value; my_function(&value); When returning references, rust uses the lifetimes instead of explicit declarations to figure out where (on the stack) `value` needs to be allocated. OMG, thank you for including this. I spent several months reading every bit of documentation that was available f…

> But I don't know if technical details such as this are high enough on the priority list. There are actual features which still have no documentation. It's hard being a single person trying to keep up with changes from tons of other people, many full time and some community. I may be the person who is most looking forward to Rust being stable...

> I may be the person who is most looking forward to Rust being stable...

No, that would be me! :)

Re: Some notes on Rust

#69

Post by Animats »

NotableAlamode wrote: post #64
Animats wrote: post #58

Wow. I wrote that article on LtU last night, after going over there to see what the language theorists were saying about Rust. (And after, for the third time in three weeks, having my Rust code fail to compile because the Rust crowd changed the language again, after the "alpha release" and its claims of stability: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html ) I wasn't expecting it to be picked up on Hacker…

Just a historical note: Rust's ownership system has much historical pedigree, such as the Cyclone language and the work on ML compilers with region inference, following Tofte and Talpin's pioneering work. The Wikipedia article ( https://en.wikipedia.org/wiki/Region-based_memory_management... ) has a good overview.

I know, I wrote one of the early papers: Strict Mode for C++ (2001): http://animats.com/papers/languages/cppstrictpointers.html Further back, Ada has region-based memory allocation.

Around 2002, when there was concern about computer-related terrorism, I suggested that the C++ standards committee's unwillingness to deal with memory safety constituted material support of terrorism. They were angry, and terrified. That post was actually deleted from their USENET group.

Post reply on HN