Live data from Hacker News

Guaranteeing memory safety in Rust [video]

air.mozilla.org

1–10 of 28 posts

Re: Guaranteeing memory safety in Rust [video]

#4
post #3

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.

This is a good reminder that speakers should always repeat the question on mic during Q&A. :)

Re: Guaranteeing memory safety in Rust [video]

#5
post #2

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.

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

Re: Guaranteeing memory safety in Rust [video]

#6
post #3

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.

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]?

Re: Guaranteeing memory safety in Rust [video]

#7
post #3

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.

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].

Re: Guaranteeing memory safety in Rust [video]

#9
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.

Re: Guaranteeing memory safety in Rust [video]

#10

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

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.

Post reply on HN