Guaranteeing memory safety in Rust [video] (opens in new tab)

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

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

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

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

Some of the Rust features can be disabled via compiler flags, on the other hand I rather pay a little bit for security.