Rust 2019 -- The Road Ahead

08 December 2018

The Rust community team is soliciting blog posts to help plan the 2019 efforts. So here’s my take. I’ll start by looking back at the last year. We’ve seen great and impactful changes in the Rust landscape, such as non-lexical lifetimes, the stabilization of procedural macros and const fn, stable clippy and rustfmt, the further development of powerful IDE integration such as IntelliJ, Atom and VSCode.

mutagen shows that using a Rust procedural macro for mutation testing is at least possible (though it’s currently broken and in need of porting to the new procedural macro interface). WASM has brought Rust into the web arena where it is now a major player. Fedora and Debian ship Rust code by default. Project Quantum has brought Rust to Firefox, and integration work continues. Companies like Google, Oracle and Dropbox have adopted Rust for high-profile projects, and some game companies even started using it for all new work. The embedded Rust community is vibrant, and getting Rust code to run on small ARM cortex M boards is now positively easy.

Not all is great, though. We still lack a lot of tools, for example, localizing Rust code is not yet trivial. While documentation has generally improved (and that’s starting from a good state compared to what other young languages have to offer), there is still a lot of work to be done. Things like specialization and generic type constructors have been discussed for months now, and appear to be blocked on the new type system implementation.

The growth of the community has brought new challenges to both the community and moderation teams. Aaron Turon’s RustFest Rome Keynote highlights some of the problems coming up. Those are nice problems to have.

So what to do now? Personally, in no particular order, I’d like to see:

implementation of the Macro Expansion for Macro Input RFC, which has seen really good progress in the last weeks

implementation and stabilization of Aaron’s specialization proposal (this would have me port overflower and mutagen, but having both finally work on stable would greatly expand their userbase)

const generics (as in being generic over e.g. numbers), which have been a requested feature since well before Rust 1.0 – no more hacks like typenum

sorting out the std vs. nostd problems. I’d love to have shared code for most things (and, say, allow libcore to use things like process::Termination ), but pulling in fmt isn’t going to fly here

), but pulling in isn’t going to fly here a workable cross-platform GUI library that abstracts over the smallest, most thrifty platform libraries (sort of like a reduced FLTK, but with the components written in and for Rust and backends for Windows, MacOS, X11, Wayland, Android, iOS, perhaps WASM?)

a new pre- #[cfg] -expansion lint interface

-expansion lint interface continuing fine-tuning of our processes, especially at the RFC level, adding more mentoring and outreach to help more people find more positive-sum outcomes

stabilizing and developing more tools for library creators to help them help their users, e.g. more #[must_use] tweaks, more annotations to allow library authors to improve error messages for various tasks

tweaks, more annotations to allow library authors to improve error messages for various tasks more marketing geared towards companies at various levels. Rust has made a great start, let’s redouble our efforts to cross the chasm from early adopters to mainstream

So here we are – I’m very hopeful that Rust will have a shining future. What are your thoughts?