Rust 2020 - Rust needs to be boring

This blog post is a response to the call for blogs from the Rust Core Team.

I’ve been following Rust for long enough that I remember the early days (pre 1.0) where the language would keep changing from under me and I’d have to regularly rewrite parts of my project using the latest syntax. Fun times!

Of course, things have changed a lot since then. The language has stabilized and we have Rust Editions to rely on for major releases. However, even though changes to the language are backwards compatible, there is still quite a lot of churn due to new features being added.

For example, there are some eagerly await!ed syntax changes that just landed in Rust 1.39 (see what I did there?) that will cause many projects in the ecosystem to go through some refactoring to take advantage of this new functionality and this in turn will ultimately require many of us to refactor our own projects if we want to be able to use the latest and greatest releases of these libraries and frameworks.

While the benefit of these changes outweighs the cost of refactoring for many of us, it is still additional work, and for some companies (particularly larger companies) this kind of momentum can make Rust seem too risky to adopt right now.

Some larger companies follow Dan McKinley’s advice that one should Choose Boring Technology (well worth a read) and currently Rust does not qualify. These companies will potentially perceive Rust as a shiny new thing that developers are chasing that could turn out to be a fad.

So how can we make Rust boring? I think we already are and this progress will continue through the growing and maturing ecosystem of essential libraries and frameworks, through the maturing IDE support, through the growing community, and through the success stories we see in our newsfeeds.

Realistically though, it will be quite some time before Rust is truly boring, so what can we do in the meantime? My advice to developers wanting to introduce Rust into their jobs where it is a safer bet to stick with languages that existed in the previous century (C, C++, Java, PHP, Ruby, JavaScript, and so on) is to consider these points:

• Focus on use cases where the justification clearly outweighs the costs (security, large scale data processing, low latency networking, etc).
• Demonstrate the benefits through a proof of concept and make the arguments based on the facts and numbers (performance, TCO, time to market, support overhead) compared to viable alternatives.
• Try not to talk too enthusiastically about the benefits of the Rust programming language and why it is better than everything that came before. This can be dismissed as a religious argument.

As a last resort, if you are really passionate about using Rust, the good news is that there are an increasing number of companies using Rust that would welcome developers that want to be at the forefront of innovation to give them a competitive edge over their competitors.

If you are not fortunate enough to be using Rust in your day job then maybe 2020 is the year you can make it happen!

Of course, I haven’t suggested anything specific yet that could result in an RFC for Rust, but I think we should consider a Rust 2021 edition now that we have async/await and a large focus for 2020 could be stabilizing key crates that can benefit from this functionality.

Want to learn more about query engines? Check out my book "How Query Engines Work".