Guaranteeing memory safety in Rust [video]

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

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.

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

I'm not an expert about concurrency, but from my understanding Go still does not solve the safety issues relating to data races. In addition, Rust's concurrency 'primitives' are built as libraries rather than into the language itself, making them far more powerful and extensible. That said, Rust pays for this power and safety with a steeper learning curve and a more complex type system, but in my opinion it's worth it.

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.