My Wishes for Rust 2019

rust 2018-12-14

2018 was a massive year for rust, and it's great to reflect back on how far we've all come. My main wish for the new year is to put on the breaks a little bit, and finish off what has been started without taking on anything majorly new.

There are a couple of areas that I feel need more attention than most (purely for selfish reasons of course!):

Compiler Times, IDE Support and RLS

I think RLS is great. I think cargo check is great too. Sometimes when I am waiting for RLS to finish in VSCode, I run cargo check in a terminal to see who wins the race. Sometimes I get results faster from the cargo check than I do in RLS. I'm not sure why that is, it might be that I'm making a lot of small edits, and RLS is constantly restarting. I am assuming that the plumbing for both methods is rather similar. On average, if I just adjust whitespace on one of my projects, it takes at least 10 seconds to recompile. If I change any trivial bit of code, this doubles to 20 seconds.

I would love to have dynamic loading in rust as a first class citizen, but I fear the ABI stabilisation is a far way off (I know you can cheat by using the C ABI and libloading but there is a fair amount of unsafe code, which I'm not comfortable with). This would alleviate some of the issues around compilation times, by allowing compilation to be broken up into smaller chunks.

For instance: I implemented a WebDAV handler with actix-web. This added a significant portion of time to compilation after the implementation was finished, and the code is mostly decoupled from the rest of the app and sits in its own little route (XML instead of JSON, etc..). I'd love to be able to just hot-load this as a module, rather than compile it in each time if I'm not even touching this part. Incremental compilation does help a little bit here.

Better IDE Support

I have been using VSCode as my primary rust IDE for a while now, which is great, but I'd love to be able to use IntelliJ as well. Each time there is an update, I do give it another shot, and find that there are a couple of problems with it:


Admittedly, each release of the IntelliJ rust plugin is better than the last, but it is not even close to the support that Java has. I am hoping that this changes in the future.

I'd also love to be able to give Oni a go, but currently it's in limbo until I, or someone else, has enough time to work out what is wrong with the Language Server Integration.


I would really love to see the async/await story come to a close in 2019. The rust team has laid the groundwork with the 2018 edition, and together with the new pinning API I feel like it's just around the corner. This has the opportunity to really change the landscape and make rust a much more productive language.

I've had a crack at writing both a multipart client & ZeroMQ library, but I can see that when the async stuff reaches stable, it's going to make life a lot easier. Kudos to the team for moving this forward (I also happen to think the logo for futures-rs is pretty rad!)

Documentation Churn

With these changes to async, there is going to be some challenges around documentation. I feel in tokio-land there is a high degree of tribal knowledge that, if you don't keep up with things, you are left behind.

There is the new futures 0.3 crate, which is not currently in use by tokio crate, you have to use futures 0.1. No-one knows what happened to 0.2, it's a mystery left for future rust historians, and 0.3 is still very much in alpha. Earlier on in the year if you went straight to the page for futures, this would direct you to the 0.3 version, which isn't helpful if you are using this in conjunction with tokio (this appears to be resolved now, by some clever use of yanking).

Another example is the move away from tokio-core into the standard tokio crate. This is something that is a great evolution for tokio, but has left a number of libraries outdated. A lot of the great blogs by pioneering devs have also become outdated when dealing with this, which increases the frustration for any newcomers. I am hoping that now things are more settled that this won't be much of an issue.

All of these changes adds to a high level of fatigue for developers. If you're not lucky enough to be working in this space day-to-day, coming back after 6 months would be daunting. There is a push to help modernise the documentation, but this hasn't seen much activity in a couple of months. I'm hoping to find some time in the new year to help out with this, as I think there is a lot of work to be done.


I think rust has come a long way and still has a long way to go. I focused a lot of energy on writing apps in rust this year, and will undoubtably accelerate the usage as time goes on.

I hope that the rust team has time to put on the breaks, and apply a bit of polish before doing anything major. I also hope I have more time to contribute some bits and pieces here and there to make the community better.