Guaranteeing memory safety in Rust [video]
air.mozilla.org
Guaranteeing memory safety in Rust [video]
1–10 of 28 posts
Re: Guaranteeing memory safety in Rust [video]
#2Re: Guaranteeing memory safety in Rust [video]
#3Re: Guaranteeing memory safety in Rust [video]
#4Was 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.
Re: Guaranteeing memory safety in Rust [video]
#5This 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.
Re: Guaranteeing memory safety in Rust [video]
#6Was 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.
~ 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]
#7Was 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 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]
#8Re: Guaranteeing memory safety in Rust [video]
#9Re: Guaranteeing memory safety in Rust [video]
#10Rust 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…
Some of the Rust features can be disabled via compiler flags, on the other hand I rather pay a little bit for security.