The End of Unsafety

The Past, Present and Future

^of

The Rust Programming Language

Brian Anderson
<banderson@mozilla.com>

Alex Crichton
<acrichton@mozilla.com>

My name is Brian Anderson, and this is my friend Alex Crichton, and we are both on the core team of the Rust programming language, as well as being employed to work on Rust by Mozilla Research.

Alex will you introduce yourself?

Alex: I've been working on Rust since 2013, where I have been responsible for large portions of the standard library and the broader library ecosystem. I'm also etc.

Brian: I've been working on Rust since 2010, involved in every aspect of its development. Much of my work has been in the standard library, tooling, platform support, community building. I have a special passion for software validation and ensuring that Rust is rock solid from release to release.

https://github.com/brson/the-end-of-unsafety

~ slides, notes, links ~

Rust

Top-tier performance (like C/C++ or better)
Memory safe (no crashes)
No runtime, no GC (runs everywhere)
Targets the same use cases as C/C++ (all of them)
Sponsored by Mozilla (makers of Firefox)

~ www.rust-lang.org ~

Rust is first and foremost a high-performance, memory safe, systems programming language. And when I say "high-performance", I don't just mean it's fast, I mean it's among the very fastest programming languages. Think C, C++, and Fortran.

And when I say "memory safe" I mean that Rust software does not crash, at least not in the way that languages like C and C++ do, where a crash can lead to unpredictable, and - most importantly - exploitable behavior.

Rust provides the very best performance without sacrificing safety.

It accomplishes this by being designed completely around safe, zero-cost abstractions. The code you write corresponds quite directly to the code the machine runs. Accordingly, Rust has no runtime, and - crucially - no garbage collector. And this makes Rust extremely portable - Rust will run on just about anything with a CPU, everything from microcontrollers to supercomputers.

Rust is a thriving, collaboratively developed open source project sponsored by Mozilla, the makers of Firefox, who employ Alex and myself.

Timeline of the End of Unsafety

The Age of Unsafety

1972 → whenever

The Creation of Rust

2009 → present

Rust Today

right now!

The Future of Rust

present → the glorious future

Disclaimers

The Age of Unsafety

1972 → whenever

What is "unsafe"?

Memory safety

The state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.

— Wikipedia

Memory safety errors

Buffer overflow
Stack overflow
Use after free
Double free
Data races
Segmentation fault

Why keep using C/C++?

Inertia
Costly to rewrite
Portability

Let's be honesthonest, if you need segfault protection, you're a bad programmer.

— Anonymous good
programmer
on the internet

A real-world example

OpenSSL

Heartbleed in detail

Missing bounds check
Dormant for two years
Private keys leaked

CVE-2015-7547

glibc: getaddrinfo stack-based buffer overflow
Multiple stack-based buffer overflows

The Creation of Rust

2009 → present

10,000,000 LOC

12,000,000 LOC

133 CVEs in 2016

203 CVEs in 2016

All 34 sec-critical bugs filed against Web Audio so far are either buffer overflows or use-after-free.

— Robert O'Callahan, Mozilla

Rust's original design / requirements

Memory safety
Thread-local, garbage-collected heaps
Green-threaded concurrency (ala Go)

Memory safety
~~Thread-local, garbage-collected heaps~~
~~Green-threaded concurrency (ala Go)~~

Now, the Rust of 2009 was much different from the Rust of today. But even then, the primary objective was to solve the memory safety problem, but the assumptions were different.

Back then, even the Rust team thought the only viable way to solve the memory safety problem was through a garbage collector, so Rust's heaps were garbage collected, but that garbage collection was thread-local. That way garbage collection in one thread would not interfere with progress in other threads. This was in important early constraint, and it influenced our ultimate solution.

Rust was, at the time, a green-threaded programming language in the style of Go, with ML influences.

(next fragment)

But these assumptions did not hold.

Rust's actual design / requirements

Memory safety
Ultimate performance
No GC or runtime at all
Traditional OS threads and concurrency

Rust's key design problem

How can I maintain memory safety in a concurrent program without a global GC?

Thread A

h
e
a
p

s
t
a
c
k

Thread B

h
e
a
p

s
t
a
c
k

Let me illustrate the problem. Here we have two isolated threads, each with its own heap (on top), and stack (on bottom).

Now, imagine I create an object in thread A's heap.

(next fragment)

Here represented by a blue balloon.

Now, imagine that thread B wants that balloon, so I send it from thread A to thread B.

(next fragment)

So far so good. But how should the language actually implement that? Well, since the Rust of 2009 had isolated heaps, perhaps we make a deep copy of the balloon, copying the balloon over to the other heap.

But what if the balloon itself contains pointers to other ballons? And what if one of those contains a pointer back into the stack? How do you deal with those?

These are hard problems to solve, and it's easy to end up back in a situation like this...

Thread A

h
e
a
p

s
t
a
c
k

Thread B

h
e
a
p

s
t
a
c
k

The Rust insight

Rust is Cyclone + Singularity

For months we batted around this problem of sending objects between threads without invalidating pointers, and without a garbage collector.

Around this time Niko Matsakis joined the team. Niko was an actual trained type theorist, and he brought some good ideas.

Niko was looking at a research project called Cyclone and wondering if we could learn from it. Cyclone was a safe dialect of C that used static analysis to track the validity of pointers.

Cyclone's system was somewhat limited and did not directly solve our multithreading problem.

But also at the same time we became aware of another research project at Microsoft called Singularity. It was an attempt to reimagine the operating system in .NET. There wasn't a lot of information coming out of Microsoft but what caught our eye was their approach to concurrency. In Singularity they employed a novel technique to transfer ownership of - and sole access to - entire regions of memory between threads, by only copying a pointer.

(next fragment)

In a real sense Rust is Cyclone plus Singularity.

And the result in Rust is what we call "ownership and borrowing".

Ownership and borrowing

In Rust, every value has a single, statically-known, owning path in the code, at any time.

Pointers to values have limited duration, known as a "lifetime", that is also statically tracked.

All pointers to all values are known statically.

Move an owned value

OK, give my
balloon back

Borrow a shared reference (&)

Borrow a mutable reference (&mut)

Move an owned value


fn main() {
    let b = Balloon::new();
    examine_balloon(b);
    // accessing b here is a compilation error
    println!("still have a balloon? {}", b);
}

fn examine_balloon(b: Balloon) {
    println!("this balloon looks like {}", b);
    // b is destroyed when the function exits
}

Borrow a shared reference (&)


fn main() {
    let b = Balloon::new();
    examine_balloon(&b);
    println!("still have my balloon! {}", b);
    // b is destroyed when the function exits
}

fn examine_balloon(b: &Balloon) {
    println!("this balloon looks like {}", b);
}

Borrow a mutable reference (&mut)


fn main() {
    let mut b = Balloon::new();
    examine_balloon(&mut b);
    println!("still have my balloon! {}", b);
    // b is destroyed when the function exits
}

fn examine_balloon(b: &mut Balloon) {
    b.draw(Drawing::HappyFace);
}

Ownership and borrowing operations

Move an owned value
Borrow a shared reference (&T)
Borrow a mutable reference (&mut T)

Rust Today

right now!

Best-in-class performance

ripgrep - 8x faster than grep
webrender - hundreds of fps

Stability as a deliverable

Stable since 2015
16 point releases

Growing library ecosystem

9k crates
50k versions
150M downloads

Rust's Community

1967 contributors to rust-lang/rust
RustConf, RustFest, Rust Belt Rust

StackOverflow 2017 Survey results

RedMonk Language Rankings

By our metrics, Rust went from the 46th most popular language on GitHub to the 18th... no other language grew faster.

https://www.rust-lang.org/friends.html

The Future of Rust

present → the glorious future

Rust soft challenges

Acceptance / learning curve
Competition from other languages

So we think Rust is in a very strong position right now. It has qualities that no other language stack has, and that are not easy to achieve. But Rust's long-term success is not yet guaranteed, and it's adoption, while growing quickly, is still modest.

A big challenge is Rust's learning curve. While Rust has a reasonably familiar syntax to C++ programmers, it's semantics are just as much derived from ML and Haskell. We believe Rust's semantics are quite attractive for systems programmers, but convincing happy C++ developers of this isn't simple.

But more than that, Rust's fundamental model - ownership and borrowing - is effectively a new programming paradigm - it requires users to adapt to a new way of thinking about how they manage the resources in their code. Programmers who make that connection tend to find the Rust model significantly clarifiies their own thinking about code, but it does take investment on the programmers part, and an openness to new ideas.

It's also possible that plain competition could win over Rust. In much the same way C, a "worse is better" solution, dominated the market for decades by working in all the right places, some other language may do what Rust does just good enough. Or a new language might do Rust better than Rust.

Challenges for Rust replacing C++

C++ language interop
Build system integration

We think Rust is an excellent C++ replacement today. Both languages have similar costs and performance, but Rust has the advantage of memory safety and a clean slate.

The biggest challenge to Rust's adoption in the systems space is interoperating with the vast amounts of C++ code running the world today. Note that I say "C++" and not "C and C++". Interop with C is quite simple and Rust can masquerade as C all day. Interop with C++ on the other hand is very, very hard, and few languages do it successfully.

Along those same lines, we've already encountered a number of challenges integrating Rust into existing build systems. Rust has it's own opinionated package manager called Cargo, and while it works very well, teaching it to integrate with all the various build systems used for C and C++ is an ongoing process. This is something we're hearing a lot from users right now, and working to address.

Challenges for Rust replacing C

ABI stability (upgradable dlls)
Monomorphization (binary bloat)
Unstructured control flow (setjmp / longjmp, goto)

Rust replacing C is in some ways a simpler story than replacing C++, and some ways more complex. C is a much easier language to interop with than C++, and because of that it tends to be used for the lowest layers of the stack, in system libraries and operating system kernels.

The big thing that Rust needs to make inroads at that level is ABI stability - that is, the capacity to do seamless upgrades of dynamic libraries between point releases. Today Rust provides very strong source stability, but not binary stability.

Another significant technical challenge for Rust in comparison to C is its approach to generics. Rust uses a technique called "monomorphisation", which simply means that each time the Rust compiler instantiates a generic function it emits a fresh, optimized, copy of the machine code. This creates fast code, but also results in large binary sizes that C programmers are unaccustomed to.

C also provides some unique features that might not be used often, but occasionally are used to achieve performance, things like setjmp/longjmp, and computed goto. It's not clear whether Rust would adopt such features to gain parity.

Why Rust will succeed

Incredible tech
Production focus

So there definitely are some challenges, and it's going to be a long road for Rust, but they are surmountable. And we have a lot of reason to be hopeful.

Perhaps the greatest reason is that Rust's technical foundations are very, very strong. The runtimeless ownership model is a powerful base to build the entire computing stack on top of. We are thankful every week that, through some miracle, all the years of design work we did somehow left us in a real sweet spot in the design space.

And having this strong technical foundation gives us freedom to focus on getting Rust into production in more places. From the very beginning, Rust has been designed for production, to fulfill the needs of Firefox, a product used by 100 million people. And now we are in a position where if we just keep knocking down obstacles to production deployment, Rust will see wider and wider use. Our published roadmap for 2017 is almost entirely about clearing the way for production users.

Why Rust will succeed

Flexible ecosystem design

Another major systemic advantage we have built into Rust is the design of its library ecosystem, and the separation between the language and the libraries. Rust is quite modular, with much of its capabilities being provided by libraries. For example, Rust knows nothing about concurrency, but its libraries leverage ownership and borrowing to provide very robust and foolproof concurrency abstractions.

The Rust standard library itself is quite small, providing core data structures and operating system abstractions. Everything else is provided via Rust's package manager Cargo and the library ecosystem. This was a very intentional decision to ensure both a high quality core product, and to encourage free and rapid experimentation in the Rust community, and it has paid off well - we see great libraries coming out of the Rust community, and as they mature they will be adopted into the Rust cannon.

Why Rust will succeed

Expanded systems audience
Strong culture

The convenience, flexibility, and robustness of the Rust system is additionally going to vastly expand the audience of systems programmers.

With Rust, systems programming is easy and accessible.

This is one of the biggest revelations we've had in Rust's development - that there are vast audiences that want to write low level code but don't want to write C and C++. We see a lot of young programmers with backgrounds in Ruby and JavaScript getting into Rust, and creating their own high-performance systems software for the first time.

And this points to Rust's greatest strength - it's culture and community.

In Rust we are building a new systems programming culture, and it is going to be expansive and welcoming and accessible, and it is going to change the nature of systems programming for the better.

What's coming up in Rust?

Improved ergonomics
`tokio` (really fast async I/O)
Docs (reference, APIs, guidelines)
Tooling (IDEs, embedded)
Language interop (incl. JS, Ruby, C++)

There's a lot going on in Rust, but let's talk about a few of the big things.

(next)

The most important thing we are doing right now is improving Rust's erogomics. Rust is a very powerful system, but it has some rough edges, and those especially impact new users. There are a number of changes coming up that will make Rust even more fun to use than it is today.

(next)

The next big thing is asynchronous I/O, via a project called "tokio". Async I/O is how you do fast I/O in the modern world. If you are familiar with node.js with it's callbacks, that's async I/O. We are hopeful that tokio is going to become the fastest and most robust async I/O stack there is. This is going to be a big enabler for Rust developers, and we expect to see some impressive software built on it. Alex is giving a talk on this tomorrow.

(next)

In Rust we value documentation. Already, we hear a lot of praise for the quality of our docs, but we're not going to let up. In the next year we'll be publishing a completed language reference, thoroughly documenting all the most important Rust libraries, and proving guidance on designing APIs the Rust way.

(next)

A programming language is not competitive today unless it has strong tooling. Developers have high expectations. We're creating a new program called the Rust Language Server, an IDE-agnostic server that provides the metadata and analysis required to fulfill the typical functionality of an IDE. And we're integrating that with Visual Studio Code.

That's going to be released this summer.

(next)

Finally, I've already spoken about the importance of interop, but it's not just with C and C++. Because Rust has no runtime, it's easy to embed in any language stack, and we see a lot of demand for that. When you have a Rails application that needs to be accelerated, and your choices are memory-unsafe C, and Rust, that choice should be easy. We think this is a major avenue for Rust adoption.

Brian Anderson
<banderson@mozilla.com>

Alex Crichton
<acrichton@mozilla.com>

The End of Unsafety

https://github.com/brson/the-end-of-unsafety