As Rust 1.0 official release approaches, Mozilla Research’s Niko Matsakis has set out an initial assessment of priorities for new features to be added to the language in the future. This is meant as a way to trigger a public discussion about the direction that the Rust language should take. InfoQ has spoken with Matsakis.

Matsakis’ assessment groups features in three priority tiers, based on their time-sensitiveness, i.e., features becoming harder and harder to add over time, and their overall impact on Rust developers’ community or the range of problems that a feature can solve.

Among the top priority features, Matsakis lists:

Library APIs stabilization, e.g. the Filesystem APIs and Memory allocation APIs.

Better Windows and ARM support, which boils down to remove Rust dependence on MinGW and support ARM64.

Faster compilation.

Better tooling support.

Allocators/tracing providing more control over memory allocation.

Specialization, that allows to define multiple implementations of a given trait for a given set of types.

Virtual structs, allowing some form of inheritance across structs.

Other features, according to Matsakis, could get high priority status, such as improving macros and syntax extension, and other still are classified as mid-priority, or longer term. InfoQ took the chance to speak to Niko Matsakis to learn more about Rust status and its future.

Now that Rust 1.0 is almost out of the door, what are your feelings about it? Do you think the language has reached a good maturity level?

One of the things that makes me feel most confident that Rust is ready for the 1.0 release is the rapidly growing community and ecosystem. There are almost 2,000 crates in the crates.io repository now, and Rust is also being used in some pretty big projects (e.g., the Rust compiler itself, Servo, and Skylight). The current design of Rust is the result of quite a lot of iteration, and I think that iteration has really paid off. Still, exciting as the 1.0 release is, I think it’s really just the beginning. We’ve got a lot of plans for improvements, and I look forward to seeing them take shape. I’m particularly pleased about the way that the project has been taking on such an open, public character; having a large group of contributors has really helped improve both the design and implementation of Rust, and I think that will only be more true after 1.0.

Rust has been attracting a lot of attention thanks to its support for modern programming language ideas such as option types, generics, type inference, etc., while still being somewhat low-level. Could you elaborate on the importance of those ideas for low-level programming?

For those cases where performance really counts, having low-level control over your machine can be a real advantage. But right now, it generally comes at a steep price in productivity. We always expected Rust to appeal to C++ programmers, but what we didn’t realize is how appealing Rust would be to people coming from higher-level languages. The type system is the key here: Rust’s type system is the means for enforcing safe patterns, like ownership and borrowing, that avoid crashes and make low-level programming faster and easier. This in turn means that you don’t have to be an expert in systems programming to deploy a Rust app in production or write a library for crates.io. From a language geek’s perspective, we combined a bunch of great ideas from modern languages and brought them to systems programming. But the net effect is low-level programming without the crashes and pain.

Beyond feature priorities, could you tell us where is Rust headed, in your view? What are the kind of features that we can expect to appear in future’s Rust?