Rust, the superficially low-level language developed by Firefox progenitors Mozilla, has been quietly under development for the past seven years. With the language having hit version 1.0 in May 2015 however, the company is now on a marketing drive. At a well-received session at QCon London last week, Mozilla Research Engineer Felix Klock took to the stage to discuss the core concepts of Rust, and how it’s helping to illuminate systems programming for so-called “script programmers.”
With the push to promote Rust well underway, it’s been an exciting year for Klock and his team. Before the GA release of Rust 1.0, the language had been in a constant state of flux – not ideal for consolidating a user base, and as Klock admits, fairly off-putting for potential converts to the language. As he comments, “I don’t know how many people tried it out over the years, but left rapidly because their code didn’t stay stable because we just revised so much stuff.”
Akin to Scala, Rust has been cooked up by a highly academic team of programmers – albeit supplemented with the experience garnered from Mozilla’s work in the browser space, which is very much grounded in “the real world.” Almost all the people involved, Klock says, have a pretty academic background, and there is “super appreciation for academic work”at the company. For this reason, in the early days, it was crucial that they had the time to experiment and find their way with the language.
Ultimately though, the moment came when the team realised they had a “viable product” on their hands. And at that point, the decision was made to freeze the established features. Although Klock notes that the team “recognise we’ve made mistakes with some things, and some things could be better,” he is adamant that, going forward, they will continue to support any features in the 1.0 to the best of their abilities – with the exception being anything which it turns out flouts their self-imposed safety guarantee.
Musing on the difficulties of formalising a 1.0 version of a new language, Klock says, “We were very careful to choose a subset that we believe to be stable – there’s no formal proofs or anything about safety right now, but we were confident we’ve made pretty good choices. However, we’ve also given ourselves freedom for new innovations, and new APIs for things that will expand the language. This is super important because in Mozilla…the majority of people working on Rust are in the research team. This is a research topic for us – even if it’s being deployed for production use.”
Where Does Rust Go?
Although Rust is indeed being deployed in production, one of the language’s defining features is its ability to scale everything from web browsers to entire operating systems. Whilst this prismatic scope for use case scenarios is a big potential sales asset, it does make it difficult for Mozilla to pinpoint one niche group to target for adoption.
In terms of the first target group, Klock recalls, “We weren’t sure if we could convince people to write a whole application stack in Rust, that might be a bit of a hard sell – but, the intention was, you can embed this. If you take your existing code – whatever native interface stuff you have with Java, or native Ruby code, for example – we wanted Rust to be pluggable the same way you can do an extension in C for those contexts. We wanted you to use Rust for the same thing. That was the initial audience.”
However, as it turned out, there were users who took on the challenge of executing an entire stack in Rust. For Klock, this is “super exciting,” but also a little scary because, as he says, “you have to support them…and it does change the dynamics of the choices you make as developers of course.”
As for the future areas of uptake, Klock says, “It’s not clear to me where it’s going to really go.” They’ve seen a number of student and hobbyists trying to apply Rust for game development, but that’s a difficult space because, for the most part, their concerns do not chime with the those of the development team. But at the same time, Klock states, “we have other people who are looking at other features of that are exciting enough that they don’t necessarily care about the soundness aspects. There are other things that they’re so excited about and they want to try and deploy it in those spaces.”
Klock also has high hopes for uptake in the web services space, as well as the burgeoning IoT sector, where, naturally, Mozilla is eager to carve out a slice of the pie. These intentions were made explicitly clear in December when the Mozilla’s SVP of Connected DevicesAri Jaaksi announced a pivot away from “Firefox OS” to “Connected Devices” and plans to explore “new product innovations in the IoT space.”
At present, Klock often runs into questions about Rust and embedded devices. The research team can certainly target things like the Raspberry Pi, although the question remains whether this will prove to be a beneficial use of time. That being said, Klock affirms, “I think there’s definitely going to be interest from Mozilla in seeing it deployed in those contexts. Our perspective on what we attack is going to have to expand to include the IoT. It’s arguably already expanded to include that space, and thus, I hope that Rust will be an important player there.”
On not Being the New Go
With a similar heritage to Go and Swift, Rust is often compared to these Silicon Valley home-brew languages. However, whist Klock (grudgingly) notes some “surface syntactic similarities,” and the fact the trio are all targeting native code generation, there are some key differences. For a start, there’s Go’s use of a garbage collector, and the Rust team’s decision to forgo a JIT compiler. In this respect, Klock observes, “there’s actually a spectrum developing where people say, OK, we’re not going to use a JIT, but we’ll still have a garbage collector. That’s where Pony is. That’s where Go is. That’s not where Swift is – so Swift is more like Rust in terms of their target space. But at the same time, they don’t have quite the same fined grained controls of things we do.”
In addition, he notes, there are things like “saying this set of reference data is local to this thread, it cannot escape this thread. Swift doesn’t attempt this – it’s like C++, using atomic operations to update reference counts. And that’s relatively costly. This is a place where Rust is going to be providing both these options, and ensuring they’re used soundly. I don’t know of anyone that does that.”
Moreover, Klock highlights a number of innovations attached to Rust in terms of static analysis. “You can see some things in academia that other languages are doing, but I think we’ve hit a sweet spot in terms of being influenced by the static analyses that other academics have produced, but also casting it in a framework that end users who aren’t academics can actually hope to understand. It’s not easy necessarily – but the number of concepts you have to understand at once is still relatively small, which makes me hopeful that a lot of people will be able to jump on.”
On the roadmap ahead, the big issue for Mozilla to tackle is Rust’s compiler. “If you’re a C or Java developer,” he explains, “the amount of effort for the compiler base is roughly proportional. With Rust, our compiler appears quite slow, as it’s doing a lot of work to generate its code. And of course, because people may not understand this, their reaction will be to think that it doesn’t compete with other tools they are used to using. So a crucial thing we’re working on is incremental compilation.”
The overarching goal is for users to be able store intermediate build products in a way that they can use as much of them as they can without having to re-do all the work and process the input from scratch. Klock regards this as “a hugely important thing”, identifying the superficially laggy compilation in Rust as “one of our biggest barriers – both for adoption and even for our internal efficiency.” Once that work is done, Klock predicts a massive increase in both internal efficiency in being able to iterate faster, and in benefits to the end users.