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

21–30 of 161 posts

Re: A 30 minute introduction to Rust

#21

Post by pcwalton »

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 same logic also prevents iterator invalidation and use-after-free, which are things that do occur in the real world and lead to security vulnerabilities.

> Does Rust really call its threads "green threads"? Green threads have a weird reputation.

They're M:N threads, multiplexed among multiple hardware threads, like Go or Erlang.

> Does the whole concept of Rust concurrency and memory protection boil down to "the language provides an 'unsafe', and then people write libraries to do things with it"?

Sort of, but I think that's an uncharitable way to say it. The trick is that the language allows these unsafely-implemented primitives to be safely used from safe code. As long as the unsafe code is correct, the safe code is guaranteed to be safe. From a trust point of view this is really no different from building the features into the compiler: either you trust the compiler (which, as it's a compiler, is unsafe) or you trust the unsafe portions of the standard library. But it's way easier, and more flexible, to hack on libraries than to hack things into the compiler—as you get to write code, not code to generate code.

Furthermore, the safe part of the language is so powerful that you rarely ever need "unsafe": you can do practically everything you might need to do, including shared memory with locks, in the safe language, without GC. Only if you really need to squeeze out the last amount of performance, or if you need to interface with C libraries, do you need "unsafe".

Re: A 30 minute introduction to Rust

#22

Post by steveklabnik »

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.

Re: A 30 minute introduction to Rust

#23

Post by lucian1900 »

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…

Rust's tasks can either use native threads or green threads multiplexed on top of a pool of native threads, without change in API.

Re: A 30 minute introduction to Rust

#24

Post by ash »

steveklabnik wrote: post #10
ash wrote: post #7

Earlier quoted context omitted.

From the article: > But wait, how is that possible? We can’t both allow and disallow mutable state. What gives? I had to re-read the above a few times. And still don't get it. Steve, what do you mean with it? Are you talking about how are Arc/RWArc implemented? Or is it something else?

The previous sentence is "We gain the efficiency of shared mutable state, while retaining the safety of disallowing shared mutable state." I also wasn't sure about the part you quoted, but I was trying to explain that it's not that Rust _doesn't_ allow shared mutable state, it's that while the language doesn't, you can use unsafe to build safe abstractions, so in practice, it does. Hmmm.

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` part don't really connect them, at least to me.

Re: A 30 minute introduction to Rust

#25

Post by steveklabnik »

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…

> That's just a simple example. The same logic also prevents iterator invalidation and use-after-free, which are things that do occur in the real world and lead to security vulnerabilities.

Maybe I should mention some of the more complicated examples explicitly, then?

Re: A 30 minute introduction to Rust

#26

Post by pcwalton »

patrickaljord wrote: post #5

Thanks for the the tutorial! Rust seems a bit too complex to me. Like a C++ on steroid that wants to do and be everything. Nothing wrong with that but not my cup of tea. I'd rather stick to C if I need tight memory management, it is way simpler and straight forward. And if I need concurrency, I'll stick to Golang (or erlang). Really, it's such a pleasure to read some golang after reading this 30 minutes of Rust. Anyw…

> Rust seems a bit too complex to me. Like a C++ on steroid that wants to do and be everything.

No, that's explicitly not a goal. The goal is to enable zero-cost abstractions and memory safety. Everything here is in service of that goal.

> I'd rather stick to C if I need tight memory management, it is way simpler and straight forward.

The problem is that the "simple and straightforward" model of C leads to a lot of very not-simple-and-straightforward time in front of Valgrind to get the program to work, or worse, to fix security vulnerabilities.

Re: A 30 minute introduction to Rust

#27

Post by maxerickson »

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 sure lots of people think my view is stupid.

Re: A 30 minute introduction to Rust

#28

Post by steveklabnik »

ash wrote: post #24
steveklabnik wrote: post #10

Earlier quoted context omitted.

The previous sentence is "We gain the efficiency of shared mutable state, while retaining the safety of disallowing shared mutable state." I also wasn't sure about the part you quoted, but I was trying to explain that it's not that Rust _doesn't_ allow shared mutable state, it's that while the language doesn't, you can use unsafe to build safe abstractions, so in practice, it does. Hmmm.

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 with those two sentences. Maybe I should just straight-up remove them.

Re: A 30 minute introduction to Rust

#29

Post by brson »

steveklabnik wrote: post #25
pcwalton wrote: post #21

Earlier quoted context omitted.

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

> That's just a simple example. The same logic also prevents iterator invalidation and use-after-free, which are things that do occur in the real world and lead to security vulnerabilities. Maybe I should mention some of the more complicated examples explicitly, then?

I wouldn't want it to get too in-depth. Maybe just mention that this is a simple example but Rust prevents many other types of related errors.

Re: A 30 minute introduction to Rust

#30

Post by steveklabnik »

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 way to demonstrate these concepts in a way without 'the reveal'? It seems to me that comparison will always feel a bit reveal-y, as demonstrating some kind of difference is inherent in comparison.

Post reply on HN