Rust is a systems programming language developed by Mozilla and targeted at high performance applications. This post contains an interview with Graydon Hoare, Rust’s creator.
Graydon Hoare, a "language engineer by trade" as he calls himself, started working on a new programming language called Rust in 2006. Mozilla became interested in this new language, creating a team to continue its development and started using it for the experimental Servo Parallel Browser Project.
Rust is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. While Rust’s syntax strongly resembles C, there are major differences, some of its most interesting features being:
- Pattern matching and algebraic data types (enums)
- Task-based concurrency. Lightweight tasks can run in parallel without sharing any memory
- Higher-order functions (closures)
- Polymorphism, combining Java-like interfaces and Haskell-like type classes
- Generics
- No buffer overflow
- Immutable by default
- A non-blocking garbage collector
Mozilla has recently released a new alpha version of Rust and there is a roadmap with features to be implemented in the near future. InfoQ has talked to Hoare to find out more about Rust from an insider.
InfoQ: I understand that you started working on Rust back in 2006. Please tell us a little bit about its inception and the road to the current status.
GH: I'm a language engineer by trade and usually this means I'm working on compilers or tools for other languages I didn't have any part in designing. Naturally this sort of thing leads a person to sketch their own hobby projects. I've been doing so for a long time and finally decided to show one such prototype I'd been working on in my spare time to my manager at the time. Mozilla took an interest and set up a team to work on this language as a component of longer-term project to rebuild their browser stack around safer, more concurrent, easier technologies than C++. That larger project is called "servo". Mozilla is funding Rust development because of that.
Our current status is that we released a bootstrap compiler in 2010, bootstrapped out of that into a self-hosted compiler last year, and just finished our third (0.3) alpha release of that second compiler. We will proceed through a sequence of alpha and beta releases and then branch off a stable version, which we'll support at least as long as we're using it in production, possibly longer. Meanwhile the servo project is dogfooding our work, as we are ourselves when writing the compiler.
InfoQ: Why a new language?
GH: A lot of obvious good ideas, known and loved in other languages, haven't made it into widely-used systems languages, or are deployed in languages that have very poor (unsafe, concurrency-hostile) memory models. There were a lot of good competitors in the late 70s and early 80s in that space, and I wanted to revive some of their ideas and give them another go, on the theory that circumstances have changed: the internet is highly concurrent and highly security-conscious, so the design-tradeoffs that always favor C and C++ (for example) have been shifting.
InfoQ: Why related to C and not Java or another language?
GH: Look around, most systems code below a certain layer in the stack is written in C and C++. That's the space we're targeting.
InfoQ: What makes it better than C?
GH: Primarily, it's just much safer, less likely to crash. Your code really has to mean it, if it's going to do something memory-unsafe. And we don't tax you too much for that memory safety, unlike fully garbage-collected systems. Various other conveniences are also worth noting: the memory model translates to a safe concurrency model, and there's good support for the usual modern conveniences like closures, traits, namespaces, destructors, Unicode, type inference, immutable memory, disjoint unions, etc.
InfoQ: How does it compare with Google Go?
GH: Go's a good language. It's less complex than Rust, but also less ambitious. So you can pick your poison. Go's memory model, for example, has no concept of isolating memory between co-routines or threads, nor of controlling mutability. Everything can always race on the same global mutable heap. Similarly it has only one kind of pointer, which can always be null, and all pointers in all co-routines are subject to a single, global garbage collector. Rust statically differentiates all these cases, divides memory and pointers up into different types, which means we can control safety and performance much better, but at the cost of the programmer having to think more. Rust also provides a few extra "modern bits" that Go lacks: generic types, destructors, disjoint unions, that sort of thing. But to its credit, Go gets a lot of mileage out of the stuff it included, and I'm glad it's making headway.
InfoQ: What are Rust’s main features?
GH: I've mentioned many of them already here. I don't think a language really ought to have "main" features; it needs to have a solid, broad combination of familiar features that all fit together well, to make it easy to write, maintain and debug good, safe, efficient code. That's our aim. It's a very pluralistic aim. If the language is only good at one thing, it'll be a failure.
InfoQ: Why would developers choose Rust?
GH: Our target audience is "frustrated C++ developers". I mean, that's _us_. So if you are in a similar situation we're in, repeatedly finding yourself forced to pick C++ for systems-level work due to its performance and deployment characteristics, but would like something safer and less painful, we hope we can provide that.
InfoQ: When do you plan to release 1.0?
GH: There's a roadmap on our wiki. When it's done (assuming it doesn't grow much new stuff) we'll call it 1.0. My guess is sometime in the coming year, but I am only one member of the team now and we all know how hard it is to predict software schedules, even when you're doing something simple. This is not really a simple project.
I should note that this is all MIT-licensed work, so anyone is free to fork, port, modify, add-to or do more-or-less whatever they like with it at any time. You can also watch all our work in real time; it's all public on github, our mailing list and IRC server, the wiki and archives, etc. We welcome feedback on anything we're doing, so long as it's polite and constructive.