Interview with Aaron Turon

QCon: I've heard you say that Rust is a language designed to change historical tradeoffs in languages. What does that mean?

Aaron: So, for a long time, you had a basic choice when it came to programming languages.

You could go with something low level that gives you a lot control over the machine (like C or C++). You might choose these languages if you’re writing a game, a browser, or an operating system. You choose these languages when you need total control, and you couldn’t have any overhead. You had that language choice. You also other classes of higher-level languages that don’t give you the same control, but instead they give you much more safety. What I mean by this is you aren't going to be open to the kind of exploits like security holes that you get with C and C++, segfaults when you're trying to debug, or the kind of mistakes you can make with C++ (that are can be really hard to track down).

In something like Java or C#, you’ve got the garbage collector, and you’re not manually managing memory. It's generally a little easier (and safer) to program, but you’ve given up control over the machine.

So, for a long time, it’s been an either or thing.

You could kind of choose between that trade off. The point of Rust is to give you both. It’s not gonna be a tradeoff anymore. Rust is a language that is as low level as C++ and gives you that degree of control you need. Yet, Rust feels as higher level and easy to use as Java, and it gives you the same kind of safety that you get in Java.

QCon: How are you seeing Rust used today? Are people embedding Rust into other applications?

Aaron: Rust just went 1.0 in May. So, as you would expect, most people we’re talking to are taking an incremental approach.

In terms of the embedding story, that’s a huge part of what we’ve tried to do with Rust. Because we’re so low level, one of the things that means is we don’t have a big run-time system or garbage collector or any of that stuff that’s required for higher-level languages.

What that means is we can run Rust code in a wide variety of places that’s hard for higher level languages. If you wanted to integrate a piece of Go code and a piece of Java code with two totally different runtime systems and garbage collectors at play, you’re gonna have a bad time.

But every language out there knows how to talk to C and Rust is very good at looking just like C from the outside. So that means, we have projects going for embedding Rust code in with Ruby, Python, JavaScript, Java, and .Net. You name it.

The value proposition becomes: you’ve got the bulk of your product written (in whatever existing language you’ve invested in), but there’s certain pockets where you’re hitting a wall in terms of performance. With Rust, you can rewrite just those parts of the code. You can set up a C interface to them, and now you’re good to go.

QCon: Is Rust a magic bullet for concurrency?

Aaron: There are a lot of people talking about the multicore revolution and concurrency. A lot of what you hear is that shared state concurrency is evil, and it's the root of the problem. You hear things like we need to move to something completely different. Rust's answer is shared state concurrency is okay if you are disciplined about ownership. For example, in Rust the locks are set up so they actually say what data they are protecting. It is actually impossible to access data that is supposed to be protected by a lock if you don't have that lock held. That is just a bug you cannot make in Rust.

So there are a number of things along those lines when it comes to concurrency with Rust. So, no, Rust is not going to make concurrent programming trivial, but it sort of rehabilitates shared state concurrency and makes it much more feasible. And we can prove it because we built this browser engine that is highly, highly concurrent, and there is no way we could have done that without the Rust model.

QCon: What does ownership mean?

Aaron: Let me try to give you a concise summary. One of the hardest things that happens in programming is you have some data out there and lots of other pieces of data in your program point to that same piece of data. It's hard to keep track of everything that might be referencing it.

That often means you modify some data through one path and don't realize that it screws up some other path that could get at it. Or you might deallocate that piece of data at some point not realizing that something else was referencing to it. Now you've got a dangling pointer, and it's going to lead to a crash.

So ownership is a programming discipline that everybody follows when they are writing code (because you have to follow this). If you are writing C++, you know a lot about it because you are effectively saying when memory is free to be de-allocated. That means you know you are the sole owner of that piece of memory. There are no other pointers to it out there. So if you look at documentation around various C or C++ API's they are often telling you things like, this pointer is going to be de-allocated in this call or this pointer is owned by the caller and the caller should de-allocate it.

The same thing happens in languages like Java. It's not so much manual memory management of course, but it is for other kinds of resources like files or locks. These are also things that you have to worry about. Who owns it and when can you close it out? When can you you discard the resource in this kind of thing?

So in Rust, basically what we've done is made the discipline that everybody was following already, explicit in the compiler, as part of the type system. So when you write down the type of a function in Rust (and you are taking a pointer to some value and passing out a pointer to some other value), you actually say what kind of ownership is going on and how that relates.

I won't get into too much detail in this interview, but that's the basic point. You're actually stating explicitly, and Rust is enforcing, the kind of ownership discipline you should be following anyway.

QCon: What is Mozilla's interest in Rust?

Aaron: This whole issue about control and safety is nowhere more obvious than the browser. The browser is practically an operating system in its own right. It’s the thing that’s sitting on the frontline between your computer and a whole bunch of potentially malicious computers on the internet.

If you want to write a browser, you cannot abandon the control aspect, because browsers compete very heavily on performance. You have to get the performance aspect, but, if your browser is crashing all the time, if your browser is open to hackers, that’s a problem too.

Then there's the whole move to multi-core. If you want to take these browsers and get them to take advantage of multiple cores on an old C++ code base, that’s a nightmare. That’s basically not feasible.

So the whole idea of Rust at Mozilla was, let’s blow away these trade-offs. You know we got these ideas for how to get both safety and control. Ohh and it helps with concurrency too. The result is we built a new browser engine called Servo from the ground up. It's written in Rust has a parallelized layout system, graphic system, and it’s usable today.

It’s on track to become a product and has a much smaller code base that you have with other major browsers. It’s working great. It’s sort of taking full advantage of Rust. So, that’s where Mozilla was coming from.