For the first time, I’m writing for the Rust Roadmap blog posts call. Why this year? Maybe because after being part of the community for 3-ish years, I feel I’ve reached a level of knowledge of the language that allows me to talk about it. I’m far from being an expert, but I wrote an application of my own and I am contributing to Cobalt. Enough experience to give me some material to think about.

Rust 2018

I started to use Rust in May 2017 for a toy project to track my work time in order to learn the language. I have a vivid memory of being fighting the borrow checker and being very satisfied when the code compile and… panicking because of some off-hand unwrap. But yeah, my first crash was because of not verifying an Option before using it, not because of some ill allocated pointer.

I’m following the Rust development quite closely, so when the edition guide got out, I was quite surprised by the quantity of improvements that were already there, incrementally released during these 3 years. Each small improvement adds up and Rust feels way more polished with them. But all these progress was icing sugar on the cake that are NLL (Non-lexical lifetimes). This is really a big deal and will smooth the learning curve a lot.

Seeing the tooling being available in stable is a big relief as well, we don’t need to have nightly installed anymore to use them, particularly the trio Rustfmt, Clippy and RLS.

Rust 2019

IDE Support

The language can use more polish, and I’m sure it will, but I feel that the main effort should be on IDE support for this coming year. Rust 2018 was about productivity, but good IDE support is part of it. I remember having big hopes for the RLS in 2018 and I have been a bit disappointed by its state now that the new edition is out the door. Completion is not really precise when it works, navigation can break and we have no feedback on why the RLS is letting us down.

UI Development

If you looked at my toy project, you may have noticed that I used a curse-based UI. It wasn’t my first choice and I tried to use Gtk-rs or Relm but found them really cumbersome to use at that time (I haven’t given them another look since). This is another weakness when using Rust that need to be addressed and I think that tackling the issue early in the edition cycle can give us insight of what needs to be done without ruling out breaking changes.

Compilation Speed

With NLL, we had a slight regression on the performances, and Rust claims it’s about going fast as well, so the compiler should be fast. I have no knowledge of the Rust compiler and I know that incremental compilation is already there, so I don’t have a clear idea of how we could improve the compilation speed. I don’t even know if it’s possible giving the amount of needed checks that make Rust the awesome language we know it is. But I do hope that the team has some other tricks in its sleeves on this matter.

Installation Speed

This is less of an issue now that I don’t have to update nightly every day to get the latest bug fixes on the tooling, but the installation of the toolchain is really slow on Windows, mainly because of rust-docs and some GitHub issues are discussing this already. How can you convince that Rust is fast when its installation can take 20 minutes on a modern computer with an SSD?

Communication

Another field of improvement would be the process around the communication. It’s no secret that the new website has triggered a big big thread on the official forum, and seeing all the bugs reported gives the feeling that the matter has been rushed to get out for the new edition sake. It gives a really bad impression to the community, and it feels that past errors of communication are back again. We have this RFC process in order to take the time to think about things before doing them, so we should apply this to the website as well.

No More Rush

The release of Rust 2018 has been hit with some mistakes not detected by the preview test phase and I feel part responsible for it as I didn’t take part in the testing. Again, the new website has been hit with several 404s and the initial release of 1.31 led to broken toolchain where we couldn’t follow the commands from the announcement post to install the stable tools. Worse, the matter was not announced on the official channel so I didn’t know how to fix it and only Reddit gave me the trick to repair the whole stuff. I hope that we never encounter this situation ever again even if it means that the process needs to slow down.

Rust 2021

In the long run, after stability and productivity, I feel that the next edition should be about confidence. We keep saying that Rust is young so the ecosystem is moving a lot: new crates every day, abandoned crates as well, unstable API in many crates, no clear best crate for a specific task (e.g. for error handling, error_chain or failure?). All this gives an awkward feeling of "unconfidence" towards a technology that praises confidence in the code.

The tooling being quite rough on the edge (IDE, discoverability) is also part of the problem and I’m sure that I’m missing way more aspects that tag Rust as "too young to invest in". This lack of maturity harms the confidence that companies can have in the technology.

And last but not least, paired with this confidence, we need a big communication campaign to push adoption of Rust by vendors. More APIs that support Rust in commercial products is essential for the technology to live and gain momentum.