2015 was a huge year for Rust - we released version 1.0, we stabilised huge swathes of the language and libraries, we grew massively as a community, and we re-organised the governance of the project. I expect 2016 will not be as interesting at first blush (it's hard to beat a 1.0 release), but it will be a super-important year for Rust, and there is a lot of exciting stuff coming up. In this blog post I'll cover what I think will happen. This isn't an official position, and no promises...

2015

Before we get into my thoughts for the future, here are a few numbers for the past year.

In 2015, the Rust community:

Created 331 RFCs, of which 161 were accepted and merged, 120 people submitted an RFC, six people submitted 10 or more, Alex Crichton submitted 23.

Created 559 RFC issues.

Merged 4630 PRs into the Rust repo, authored by 831 people, of whom 91 people authored 10 or more and 446 authored one, Steve Klabnik authored 551.

Filed 4710 issues, of which 1611 are still open, from 1319 people, of whom 79 filed ten or more, Alex Crichton filed 159.

Released six stable versions of Rust (1.0 - 1.5).

Actually kept Rust stable - 96% of crates which compiled with 1.0 still compiled with 1.5.

You might be interested in what I thought this time, last year.

2016

Much like the second half of 2015, I expect to see a lot of incremental improvements in 2016 - libraries being polished, compiler bugs fixed, tools improved, and users getting happier and more numerous. There are a fair number of big items on the horizon though - we've spent a lot of time recently planning, refactoring, and consolidating, and I expect that to bear fruit this year.

Language

Impl specialisation is the ability to have multiple impls of a trait for a type, if a most specialised one can be determined. It opens up opportunities for optimisation and solves some annoying issues. There is an RFC almost ready to be accepted and the implementation is well under way. A sure bet for early 2016.

We've talked about efficient inheritance (aka virtual structs) for a while now. There is some really nice overlap with specialisation and most of a plan has been drawn up. There are still some big questions, but I hope these can be overcome.

Another type system feature that's been talked about for a while is abstract return types (sometimes referred to as impl trait ). This allows to use a trait (instead of a type) as the return value of a function. The idea is simple, but there are some really niggly issues still to work out. Still, the demand is there, so it seems like something that could happen in 2016.

A new system of allocators and placement box syntax would allow Rust to cater to a bunch of systems programming needs (e.g., specifying the allocator for a collection). It is also the gateway to garbage collected objects in Rust. Felix Klock has been working hard on the design and implementation, it should all come together this year.

The biggest language issue I'll be working on is a revamp of the macro system, in particular getting procedural macros on the road to becoming a fully-fledged, stable part of Rust. I've been exploring plans on this blog - look for the last few posts.

One area where Rust is a little weak is with error handling. We've been discussing ways to make that more ergonomic for a while now and the favourite plan is likely to be accepted as an RFC very soon. This proposal consists of a ? operator which acts like try! (e.g., you would write foo()? where today you write try!(foo()) ) and a try ... catch expression which allows for some processing of exceptions. I expect this proposal (or something very similar) to be accepted and implemented pretty soon.

We might finally get to wave goodbye to drop flags. We can dream, anyway.

Libraries

On the library front, I predict that 2016 will be the year of the crate. The standard library is looking pretty good now, and I expect that it will get only minor polish. I expect that things from outside will move into it, but probably very slowly, at least until towards the end of the year. On the other hand, there will be a lot of interesting stuff happening outside the Rust repo, both in the nursery and elsewhere.

libc has already had a revamp, I expect it to get a bunch of polish and move towards stabilisation.

rand is another nursery crate which I expect to be getting more stable, I'm not sure if there are any big changes in its future.

One of the most exciting crates around is mio, which provides very low level support for async IO. I expect to see that develop a lot and to move towards official status this year.

There are also some really exciting crates for concurrency around: crossbeam, rayon, simple_parallel, and others. I have no idea where we'll end up in this area, but I'm excited to find out!

I think 2016 will be a really exciting year for Rust tools. There is a lot coming up and it is a high priority area. Some highlights:

incremental compilation,

IDEs,

rustup/multirust rewrite and combined tool,

better cross compilation support,

better windows support,

packaging for Linux distros,

refactoring tools,

rustfmt getting better,

using Cargo to build rustc?

Community

It's been great seeing the community grow in 2015 and I hope it does even more of this in 2016. I'm looking forward to meeting more awesome people, seeing more interesting projects, more blog posts, more views on the language from different backgrounds, more meetups, more everything!

All being well, there should be at least one book published on Rust this year, hopefully more. Along with the online docs improving, I expect this will be a real boost for newcomers to Rust.

I don't know of any official plans, but I hope and expect that there will be another Rust Camp this year. Last year's event was so much fun, I'm sure a sequel would be amazing.

I also expect to see Rust getting more 'serious' - being used in production (and publicly so), being used in important open source projects, existing Rust projects maturing and becoming important in their own right, not just as Rust projects.

Some things I think won't happen

Higher kinded types - I think we all want them in some form, but it's a huge design challenge and there is already so much to be worked on. I'd be very surprised to see a solid RFC for HKT this year, never mind an implementation.

Backwards incompatibilty - we've been pretty good at keeping stable and not breaking things, I'm confident we can continue this trend.

2.0 - there's talk of having a backwards incompatible version bump at some point, but it's looking increasingly unlikely for 2016. We're doing well so far, and there is nothing obvious coming up which will require it. I'm not confident we can get away with never having 2.0, but I'd bet against it in 2016.

Happy new year

Whatever happens, I hope 2016 is a great year for the whole community. Happy new year!