6 ms·

Guaranteeing memory safety in Rust [video]

53 points by jcmoyer 12y ago

pcwalton 12y ago
This talk also doubles as a description of how to understand the memory management concepts in Rust—if you've ever wondered how to use references and boxes in Rust, this is the talk to watch.
- bjz_ 12y ago
  It also tackles head on the comparisons between Rust and C++11. Worth a watch if you are curious about that.
pohl 12y ago
Was anyone able to make out what the questions from the audience were at the end? I might need to watch this again with headphones. Great talk. Thank you for sharing this.
- cpeterso 12y ago
  This is a good reminder that speakers should always repeat the question on mic during Q&A. :)
- jruderman 12y ago
  The first set of questions was about how the borrow checker understands vectors. ~ How do you tie the ownership of [the element array] to the vector? How does the compiler know that when you take a reference into the element array, [it should treat the vector itself as borrowed]? ~ What happens if I write my own library class [instead of using one that's part of the standard library like vec]?
- jruderman 12y ago
  The last question was about using Rust for Servo, and in particular whether there had been any major pain points. Patrick Walton helped to answer (45:48): ~ The overall discipline hasn't been too difficult to been follow. ~ Most of the issues we hit are issues in the implementation. (e.g. the precise way the borrow-checker checks inveriants, reasons about lifetimes and whatnot.) These kinds of issues are fixable, and we continue to improve them all the time. ~ I don't speak for the entire Servo team, but I feel like the discipline, the overall type-system strategy that Rust enforces, has been pretty friendly. ~ We still have a lot of unsafe code, but a lot of it is unavoidable, for calling C libraries. And also we're doing things like: we have Rust objects which are managed by the SpiderMonkey [JavaScript] garbage collector. Which is really cool that we can do that, but the interface has to be written in the unsafe dialect [of Rust].
bjwbell 12y ago
Anyone else having problems with streaming? It's unwatchable for me (Comcast cable).
nwmcsween 12y ago
Rust doesn't really have zero-cost abstraction (runtime bounds checking, symbol mangling, exception handling frames, split-stacks (this may have changed?)) this was and still is my complaint about it, the one way to fix it is death by a thousand knobs that modify functionality but by then it's not even the same language. Also the recent change adding -ffuntion-sections -fdata-sections (a hack imo) shows that the language or the implementation has an issue. I may be wrong, if so let me know.
- pjmlp 12y ago
  Hackers and security tool vendors thank the success of their business to C, when better alternatives were already available. Some of the Rust features can be disabled via compiler flags, on the other hand I rather pay a little bit for security.
- bjz_ 12y ago
  Rust has bounds checking when indexing into arrays, but those can be usually bypassed by using iterators. There are also unsafe methods if you want to avoid bounds checking (but they are not recommended for most code). Split stacks were removed a long time ago.
- dbaupp 12y ago
  Bounds checking is only required for random access indexing into an array. Sequential access is very efficient (and perfectly safe) using iterators. Furthermore, if you're sure an access is always valid, you can use call the unchecked indexing method. (This requires an `unsafe` block to call: i.e. risk-of-unsafety is opt-in, but it is still easily possible on a case-by-case basis.) Symbol mangling and exception handling can be disabled. Split stacks are gone, but, at the moment, the prelude for checking stack bounds is still used to protect against stack overflow (I believe this can also be disabled).
- pcwalton 12y ago
  > runtime bounds checking In practice this is quite rare because of iterators, which do not need to do bounds checking. In the rare case in which you need to use indexes, you can always opt out of the safety without the use of a compile-time switch, exactly like the choice between C++'s "operator[]" and ".at()". The only difference is that the default is safe, and the unsafe version requires you to jump through the "unsafe{}" hoop, unlike C++. Also, with MPX on Skylake even the bounds checking may well become zero-cost. > symbol mangling How does symbol mangling make your program go slower? > exception handling frames Also enabled by default in C++, and you can turn it off just as in C++. LLVM will also optimize it out if you don't use it and use LTO. On most architectures exception handling is zero-cost via table-driven unwinding (although it can inhibit optimizations). > split-stacks (this may have changed?)) They're gone. > this was and still is my complaint about it, the one way to fix it is death by a thousand knobs that modify functionality but by then it's not even the same language. Nothing needs to be fixed, as none of the things you mention are an issue. > Also the recent change adding -ffuntion-sections -fdata-sections (a hack imo) shows that the language or the implementation has an issue. Why? Rust's compilation model is exactly the same as C++ "unity builds" (which are becoming the norm in large projects).
bsaul 12y ago
This is a fantastic video. I've been reading rapidly about rust and its types of memory pointers before, but this talks really helps me see the big picture ( aliasing & mutability, and the borrowing metaphore). Great great talk.
gkya 12y ago
The syntax of Rust was one major thing that made me avoid studying the language. Now, this talk encourages me to go and play with it. One question that comes to my mind is that how Rust concurrency compares to Go concurrency. After this talk, and some little use of “goroutines”, Rust seems to be the choice of the wise, for it being seemingly more sage and still as easy to use as Go's. I'd love to read a reply from someone who knows concurrency/parallelism, who is most definitely not me.
- twic 12y ago
  What was your beef with the syntax?
  - gkya 12y ago
    I really dislike abbreviations like “fn”, “mut”, “proc”, etc., not only in Rust but anywhere. I'd rather prefer actual words. At first, very shallow look; I thought Rust was C++ with shorter keywords (I didn't know anything about the features featured in the talk until today, though). Combined with (afaik) everything being an expression, Rust code would, I thought, become unreadable very quickly.
    - kibwen 12y ago
      I actually find the shorter keywords aid readability. Code, just like prose, has a maximum line length after which readability starts decline. Given that we only have so much horizontal space to work with, shorter keywords allow one to use more descriptive variable and function names. Given that the number of keywords is fixed and the number of variables and functions is unlimited, I'd rather be terse in the former and verbose in the latter. Also, Rust does care a great deal about readability. You might scoff at this statement, but it's true: Rust's syntax works hard to strike a balance between all of clarity, consistency, regularity, readability, and familiarity. As the language gains wider use, understanding of these constraints improves; modern Rust has removed 95% of the sigils that characterized ancient Rust. There used to be tons of sigils, and many were largely inscrutable: ~, @, +, ++, -, more that I've forgotten. Now there's only two: & (for references, a sigil taken directly from C++) and * (for unsafe pointers, a sigil taken directly from C). And there are even some people who would like to see the * sigil for unsafe pointers go away.
arthursilva 12y ago
The topics in the second half of the talk are very impressive. Looking forward to write some rust!

53 points by jcmoyer 12y ago

This talk also doubles as a description of how to understand the memory management concepts in Rust—if you've ever wondered how to use references and boxes in Rust, this is the talk to watch.

bjz_ 12y ago
It also tackles head on the comparisons between Rust and C++11. Worth a watch if you are curious about that.

pohl 12y ago

Was anyone able to make out what the questions from the audience were at the end? I might need to watch this again with headphones. Great talk. Thank you for sharing this.

cpeterso 12y ago
This is a good reminder that speakers should always repeat the question on mic during Q&A. :)
jruderman 12y ago
The first set of questions was about how the borrow checker understands vectors. ~ How do you tie the ownership of [the element array] to the vector? How does the compiler know that when you take a reference into the element array, [it should treat the vector itself as borrowed]? ~ What happens if I write my own library class [instead of using one that's part of the standard library like vec]?
jruderman 12y ago
The last question was about using Rust for Servo, and in particular whether there had been any major pain points. Patrick Walton helped to answer (45:48): ~ The overall discipline hasn't been too difficult to been follow. ~ Most of the issues we hit are issues in the implementation. (e.g. the precise way the borrow-checker checks inveriants, reasons about lifetimes and whatnot.) These kinds of issues are fixable, and we continue to improve them all the time. ~ I don't speak for the entire Servo team, but I feel like the discipline, the overall type-system strategy that Rust enforces, has been pretty friendly. ~ We still have a lot of unsafe code, but a lot of it is unavoidable, for calling C libraries. And also we're doing things like: we have Rust objects which are managed by the SpiderMonkey [JavaScript] garbage collector. Which is really cool that we can do that, but the interface has to be written in the unsafe dialect [of Rust].

bjwbell 12y ago

Anyone else having problems with streaming? It's unwatchable for me (Comcast cable).

nwmcsween 12y ago

Rust doesn't really have zero-cost abstraction (runtime bounds checking, symbol mangling, exception handling frames, split-stacks (this may have changed?)) this was and still is my complaint about it, the one way to fix it is death by a thousand knobs that modify functionality but by then it's not even the same language. Also the recent change adding -ffuntion-sections -fdata-sections (a hack imo) shows that the language or the implementation has an issue. I may be wrong, if so let me know.

pjmlp 12y ago
Hackers and security tool vendors thank the success of their business to C, when better alternatives were already available. Some of the Rust features can be disabled via compiler flags, on the other hand I rather pay a little bit for security.
bjz_ 12y ago
Rust has bounds checking when indexing into arrays, but those can be usually bypassed by using iterators. There are also unsafe methods if you want to avoid bounds checking (but they are not recommended for most code). Split stacks were removed a long time ago.
dbaupp 12y ago
Bounds checking is only required for random access indexing into an array. Sequential access is very efficient (and perfectly safe) using iterators. Furthermore, if you're sure an access is always valid, you can use call the unchecked indexing method. (This requires an `unsafe` block to call: i.e. risk-of-unsafety is opt-in, but it is still easily possible on a case-by-case basis.) Symbol mangling and exception handling can be disabled. Split stacks are gone, but, at the moment, the prelude for checking stack bounds is still used to protect against stack overflow (I believe this can also be disabled).
pcwalton 12y ago
> runtime bounds checking In practice this is quite rare because of iterators, which do not need to do bounds checking. In the rare case in which you need to use indexes, you can always opt out of the safety without the use of a compile-time switch, exactly like the choice between C++'s "operator[]" and ".at()". The only difference is that the default is safe, and the unsafe version requires you to jump through the "unsafe{}" hoop, unlike C++. Also, with MPX on Skylake even the bounds checking may well become zero-cost. > symbol mangling How does symbol mangling make your program go slower? > exception handling frames Also enabled by default in C++, and you can turn it off just as in C++. LLVM will also optimize it out if you don't use it and use LTO. On most architectures exception handling is zero-cost via table-driven unwinding (although it can inhibit optimizations). > split-stacks (this may have changed?)) They're gone. > this was and still is my complaint about it, the one way to fix it is death by a thousand knobs that modify functionality but by then it's not even the same language. Nothing needs to be fixed, as none of the things you mention are an issue. > Also the recent change adding -ffuntion-sections -fdata-sections (a hack imo) shows that the language or the implementation has an issue. Why? Rust's compilation model is exactly the same as C++ "unity builds" (which are becoming the norm in large projects).

bsaul 12y ago

This is a fantastic video. I've been reading rapidly about rust and its types of memory pointers before, but this talks really helps me see the big picture ( aliasing & mutability, and the borrowing metaphore). Great great talk.

gkya 12y ago

The syntax of Rust was one major thing that made me avoid studying the language. Now, this talk encourages me to go and play with it. One question that comes to my mind is that how Rust concurrency compares to Go concurrency. After this talk, and some little use of “goroutines”, Rust seems to be the choice of the wise, for it being seemingly more sage and still as easy to use as Go's. I'd love to read a reply from someone who knows concurrency/parallelism, who is most definitely not me.

twic 12y ago
What was your beef with the syntax?
- gkya 12y ago
  I really dislike abbreviations like “fn”, “mut”, “proc”, etc., not only in Rust but anywhere. I'd rather prefer actual words. At first, very shallow look; I thought Rust was C++ with shorter keywords (I didn't know anything about the features featured in the talk until today, though). Combined with (afaik) everything being an expression, Rust code would, I thought, become unreadable very quickly.
  - kibwen 12y ago
    I actually find the shorter keywords aid readability. Code, just like prose, has a maximum line length after which readability starts decline. Given that we only have so much horizontal space to work with, shorter keywords allow one to use more descriptive variable and function names. Given that the number of keywords is fixed and the number of variables and functions is unlimited, I'd rather be terse in the former and verbose in the latter. Also, Rust does care a great deal about readability. You might scoff at this statement, but it's true: Rust's syntax works hard to strike a balance between all of clarity, consistency, regularity, readability, and familiarity. As the language gains wider use, understanding of these constraints improves; modern Rust has removed 95% of the sigils that characterized ancient Rust. There used to be tons of sigils, and many were largely inscrutable: ~, @, +, ++, -, more that I've forgotten. Now there's only two: & (for references, a sigil taken directly from C++) and * (for unsafe pointers, a sigil taken directly from C). And there are even some people who would like to see the * sigil for unsafe pointers go away.

arthursilva 12y ago

The topics in the second half of the talk are very impressive. Looking forward to write some rust!