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

A 30 minute introduction to Rust

words.steveklabnik.com

Post reply on HN
Print view View original

31–40 of 161 posts

Re: A 30 minute introduction to Rust

#31

Post by saosebastiao »

tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

tptacek, I've been meaning to ask this question to someone with some extensive security experience: Is there a compelling story for security researchers and engineers for low-level languages with an emphasis on memory safety (like Rust or Cyclone)? From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are.

Re: A 30 minute introduction to Rust

#32

Post by ash »

steveklabnik wrote: post #28
ash wrote: post #24

Earlier quoted context omitted.

I still don't get it... And the previous sentence is now confusing for me too :) First you showed two examples: Arc (to share immutable data) and RWArc (to share mutable data with enforced mutexes around closures). Then you talked about `unsafe`. Seems easy, one needs a "backdoor" to implement RWArc in Rust (at first I thought it was implemented in C/C++). But (quoted) sentences between Arc/RWArc part and `unsafe` pa…

Ha! Bummer, maybe I will just need to re-write this paragraph. A RWArc is shared mutable state: you can have two references to the Arc in two different tasks. Yet I said that Rust throws a compiler error for shared mutable state. > (at first I thought it was implemented in C/C++). There's very little C++ in Rust anymore. :) > Seems easy, one needs a "backdoor" to implement RWArc in Rust Yup, this is exactly the point…

> Maybe I should just straight-up remove them.

Or be explicit that you'll now talk about RWArc implementation.

Re: A 30 minute introduction to Rust

#33

Post by minimax »

steveklabnik wrote: post #22
minimax wrote: post #17

I think we can be a little bit more charitable towards C++. Modern compilers will let you know if you try to do something as obviously incorrect as returning a pointer to a stack variable. $ cat > foo.cpp int *dangling(void) > { > int i = 1234; > return &i; > } > EOF $ clang++ -Werror -c foo.cpp foo.cpp:4:13: error: address of stack memory associated with local variable 'i' returned [-Werror,-Wreturn-stack-address] r…

Thank you! Maybe I should explicitly show a new/free example instead, or does that end up having a similar warning? I haven't written serious C++ in years, so I have some blind spots. Others on the Rust team have done quite a bit, so they tend to pick up my slack in exactly this manner.

I wasn't trying to undermine your argument. Rust is solving real problems. Use after free and double free are still issues in the C world. In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.

Re: A 30 minute introduction to Rust

#34

Post by maxerickson »

steveklabnik wrote: post #30
maxerickson wrote: post #27

I personally dislike the style of tutorial that has lots of 'we' and 'lets' in it. I suppose part of that comes from the tendency for such tutorials to provide revelations instead of motivators. For example, in this tutorial there is 'look at this C++ code because I said to' and then two sentences later it explains that the C++ code ends up in a garbage value. But this is probably very much a point of style and I'm s…

I tend to be very collectively focused, so I do tend to write this way. Thanks for the feedback; the style may not be appropriate for an official tutorial. > the tendency for such tutorials to provide revelations instead of motivators. I'm going to have to think about this, that's very interesting. I would like to say that my revelations provide motivation, but that may be wishful thinking... Do you think there's a w…

Well, try to state the motivation prior to the explanation.

"The second function in this C++ code does not properly initialize num":

...

"How does that happen?"

...

"Rust avoids this by"

...

Re: A 30 minute introduction to Rust

#35

Post by pcwalton »

saosebastiao wrote: post #31
tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

tptacek, I've been meaning to ask this question to someone with some extensive security experience: Is there a compelling story for security researchers and engineers for low-level languages with an emphasis on memory safety (like Rust or Cyclone)? From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-f…

> From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-flaw exploits are.

We have done measurements on this for Firefox code. 100% of the security vulnerabilities for Web Audio were memory safety flaws.

Re: A 30 minute introduction to Rust

#36

Post by brson »

I like this a lot, and think it's the best intro to Rust yet. The thing that concerns me a bit is that it presents the special cases in concurrency without impressing some of the most important points. Primarily, the channel example presents the send as copying, which in this case it is, but one of the main advantages of Rust's channels and owned types is that message passing of heap-allocated types do not need to copy. It probably doesn't stress hard enough that Rust tasks do not share memory before saying, 'oh, but really you can share memory if you need to', though I see that the Arc and RWArc examples are good ways to introduce the concept of using unsafe code to provide safe abstractions.

Re: A 30 minute introduction to Rust

#37

Post by pcwalton »

minimax wrote: post #33
steveklabnik wrote: post #22

Earlier quoted context omitted.

Thank you! Maybe I should explicitly show a new/free example instead, or does that end up having a similar warning? I haven't written serious C++ in years, so I have some blind spots. Others on the Rust team have done quite a bit, so they tend to pick up my slack in exactly this manner.

I wasn't trying to undermine your argument. Rust is solving real problems. Use after free and double free are still issues in the C world. In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.

> In modern C++ we are (hopefully) using smart pointers (std::unique_ptr, std::shared_ptr) to manage heap-allocated object lifetimes.

Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.

Re: A 30 minute introduction to Rust

#38

Post by steveklabnik »

maxerickson wrote: post #34
steveklabnik wrote: post #30

Earlier quoted context omitted.

I tend to be very collectively focused, so I do tend to write this way. Thanks for the feedback; the style may not be appropriate for an official tutorial. > the tendency for such tutorials to provide revelations instead of motivators. I'm going to have to think about this, that's very interesting. I would like to say that my revelations provide motivation, but that may be wishful thinking... Do you think there's a w…

Well, try to state the motivation prior to the explanation. "The second function in this C++ code does not properly initialize num": ... "How does that happen?" ... "Rust avoids this by" ...

Great, thank you.

Re: A 30 minute introduction to Rust

#39

Post by tptacek »

pcwalton wrote: post #21
tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

> This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. Ownership is really central to Rust. It's central to both memory management and concurrency: to work with Rust you need to understand it. > The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That's just a simple example. The sa…

I don't mean to be uncharitable; it seems like a legitimate design. I'm just wondering if there are other magic pointer types or type system features that also protect memory. To me, fewer mechanisms is better. On the other hand, building libraries to abstract unsafe pointers has been somewhat discredited by C++ and shared_ptr.

Re: A 30 minute introduction to Rust

#40

Post by tptacek »

saosebastiao wrote: post #31
tptacek wrote: post #12

This isn't so much an introduction to Rust as it is an introduction to Rust's concurrency model. The example of returning a reference to an automatic variable isn't super compelling, since every competent C/C++ programmer knows not to do it. That bug does pop up every once in awhile, but almost always in the context of a function that returns a reference to one of many different possible variables depending on some c…

tptacek, I've been meaning to ask this question to someone with some extensive security experience: Is there a compelling story for security researchers and engineers for low-level languages with an emphasis on memory safety (like Rust or Cyclone)? From my admittedly limited perspective, it seems like it could eliminate a lot of mistakes that lead to insecure software, but then again, I don't know how common memory-f…

Absolutely it does.
Post reply on HN