[steveklabnik]

> It's also true that at the moment most of, or at least a lot of, real work done in Rust eventually ends up calling into some C library.

I'm not entirely sure this is a correct claim, unless you mean 'system calls are implemented by the kernel, which is written in C.'

While it's true that FFI in Rust is really good, most things (notably, _not_ crypto) are just straight-up written in Rust.

[sanderjd]

That's fair, and I used the phrase "a lot of" intentionally vaguely. Yes, I'm thinking of calls into the system or common system libraries (like openssl), but also things like graphics libraries, e.g. sdl or glut. Certainly there are more pure-Rust turtles standing on one another than is the case in most languages, but the bottom turtle is still C.

Edit: Servo's src/support directory is a good example of my general sense that large Rust projects still tend to rely on a good deal of C libraries:

https://github.com/mozilla/servo/tree/master/src/support

[pcwalton]

Yes, and that's the primary reason why we still need to use OS sandboxing features: the Rust type system can't protect the C code that we're using, and we have to use some C code, even if it's someday just kernel32.dll. But I'm confident that the sheer number of memory-related browser vulnerabilities that have been found and continue to be found in browser engine code means that the Rust safety features are a significant security advance. It's about reducing the attack surface.