Rust 2018

I want 2018 to be boring. I don't want it to be slow, I want lots of work to happen, but I want it to be 'boring' work. We got lots of big new things in 2017 and it felt like a really exciting year (new language features, new tools, new libraries, whole new ways of programming (!), new books, new teams, etc.). That is great and really pushed Rust forward, but I feel we've accumulated a lot of technical and social debt along the way. I would like 2018 to be a year of consolidation on 2017's gains, of paying down technical debt, and polishing new things into great things. More generally, we could think of a tick-tock cadence to Rust's evolution - 2015 and 2017 were years with lots of big, new things, 2016 and 2018 should be consolidation years.

Some specifics

Not in priority order.

  • finish design and implementation of 'in flight' language features:
    • const exprs
    • modules and crates
    • macros
    • default generics
    • ergonomics initiative things
    • impl Trait
    • specialisation
    • more ...
    • stabilisation debt (there are a lot of features that are 'done' but need stabilising. This is actually a lot of work since the risk is higher at this stage than at any other point in the language design process, so although it looks like just ticking a box, it takes a lot of time and effort).
  • async/await - towards a fully integrated language feature and complete library support, so that Rust is a first choice for async programming.
  • unsafe guidelines - we need this for reliable and safe programming and to facilitate compiler optimisations. There is too much uncertainty right now.
  • web assembly support - we started at the end of 2017, there is lots of opportunity for Rust in the space.
  • compiler performance - we made some big steps in 2017 (incremental compilation), but there is lots of 'small' work to do before compiling Rust programs is fast in the common case. It's also needed for a great IDE experience.
  • error handling - the Failure library is a good start, I think it is important that we have a really solid story here. There are other important pieces too, such as ? in main, stable catch blocks, and probably some better syntax for functions which return Results.
  • IDE support - we're well on our way and made good progress in 2017. We need to release the RLS, improve compiler integration, and then there's lots of opportunity for improving the experience, for example with debugger integration and refactoring tools.
  • mature other tools (Rustfmt and Clippy should both have 1.0 releases and we should have a robust distribution mechanism)
  • Cargo
    • build system integration (we planned this out in 2017, but didn't start implementation)
    • ongoing crates.io improvements (in particular I think we need to address crate squatting - we've shied away from curating crates.io (except for security issues), but I think there is lots of low-hanging fruit for low-key moderation/curation which would drastically improve the ecosystem)
    • Xargo integration
    • rustup integration (see below)
  • Rustdoc - there's been some exciting work on the internals in 2017, I think we could make some dramatic changes to incorporate guide-like text, smart source code exploration, and easier navigation.
  • debugging
  • learning resources for intermediate-level programmers - 2017 has been great for beginner Rust programmers, in 2018 I'd like to see more documentation, talks, etc. for intermediate level programmers so that as you grow as a Rust programmer you don't fall off a support cliff, especially if you prefer not to actively engage on irc or other 'live' channels.
  • team structure - we've expanded our team structure considerably in 2017, adding several new teams and lots of new team members. I think this has all been an improvement, but it feels like unfinished work - several of the teams still feel like they're getting off the ground while others feel too big and broad.
  • polish the RFC process - the RFC process is one of Rust's great strengths and really helps where strong ahead-of-time design is required. However, it also feels pretty heavyweight, can be an overwhelming time sink, and has been a real source of stress and stop-energy on some occasions. I think we need to re-balance things a little bit, though I'm not really sure how.
  • communication channels - we have a lot of them, and none of them feel really great - many people dislike irc, it is a barrier to entry for some people, and it is hard to moderate. The discuss forums are pretty good, but don't facilitate interactive communication very well. GitHub (at least the main Rust repo) can be overwhelming and its easy to miss important information. We tried Gitter for the impl period and we've used Slack for some minor things; both seemed only OK, had their own bugs and problems, and didn't offer much over irc, plus it meant more channels to keep an eye on. r/rust is in a weird semi-official state and some people really dislike Reddit. I don't think there is a silver bullet here, but I think we can polish and improve.

Some new things

OK, there are some pressing new things that should happen. I would like to keep this list short though:

  • new epoch - it's time to do this. We should make official what shouldn't be used any more and make room for new features to be implemented 'properly'.
  • internationalisation (i18n) - I think it's really important that software is usable by as many people as possible, and I think software ecosystems do better when the tools to do so are central and official. We should develop libraries and language features to help internationalise and localise programs.
  • cargo/rustup integration - there is no reason for these to be separate programs and it increases friction for new programmers. Although it is a relatively minor thing, I think it has a big impact.
  • testing - Rust's built-in unit tests are really neat, but we also need to facilitate more powerful testing frameworks.

Prioritisation

That's a lot of stuff! And I've probably missed some libraries and community things because I'm not really up to speed with what is going on there. I think it is about right for a years work, but only if we can resist the allure of new, shiny things on top of that lot.

I'm probably a bit biased, but tools (including Cargo) seem to be an area where there is a lot of work to do and that work is important. It is also an area which feels 'under-staffed', so we either need to encourage more people to focus on tools or cut back on what we want to achieve there.

The goal

At the end of the year I want Rust to feel like a really solid, reliable choice for people choosing a programming language. I want to build on the mostly excellent reputation we have for backwards compatibility and stability without stagnation. I want the community leadership to feel like a well-functioning machine, and that the larger community feels well-represented and can trust the leadership teams. I want to feel like there are a much smaller number of projects in progress, and much fewer unanswered questions (and more projects being finished or reaching maturity). I want 'average' users to feel a good balance between innovation and stability.