Stability → Productivity → Maintainability

Tom Kaitchuck
Jan 10, 2019 · 4 min read

Rust in 2019 and beyond

In response to the call for blog posts on the direction Rust should take in 2019 and beyond I’ve come up with a few ideas.

In 2015, Rust had the goal being stable. That has been achieved. The next logical phase was to focus on productivity. Enormous gains have been made.

Image for post
Image for post

Productivity has become a strategic advantage for Rust. Take a look at modulecounts, as you can see the number of open source packages written in Rust has risen from 0 in 2015 to first surpassing Haskell, then recently Go, and soon Clojure.

Image for post
Image for post

Rust’s goal for 2021 should be maintainability. Maintenance is a major part of software development. Poor tools can make maintenance a real burden, but with the right ones we can make it a true joy. Maintainability is the next logical goal following Productivity because over the next 3 years a great deal of Rust code will be written that will need to be maintained. It also makes sense for developers and companies who are currently using Rust on low-risk or greenfield projects but will be using Rust in more critical production systems.

In order to improve something, it first must be measured. We should track progress towards Rust ecosystem goals in a centralized place. There are already several focused sites tracking progress in libraries: areweideyet, arewewebyet, arewegameyet, arewelearningyet, not-yet-awesome-rust. It would be good to have a jumping off point with all of these as well as items on the roadmap and important metrics.

Beyond tracking we need people to develop tools. Anything that brings in more developers increases the pool of potential volunteers and should be a priority. Similarly anything that makes it easier and faster to create and distribute high quality crates will provide long term dividends.

  • High quality docs for multiple skill levels will help people can continue to become more effective as they develop
  • In addition to api guidelines, it would be useful to have ‘best practices’ guide for: setting up a development environment, version control, testing, profiling, fuzzing, and connecting with online tools to do continuous integration
Image for post
Image for post
  • We currently have a hub for matching volunteers to tasks at rustaceans.org/findwork but it could be more prominent.

Cargo is a huge asset for productivity in Rust. There are a number of things we could to to continue to enhance this:

  • Enable continuous testing while editing code. If every time a file was edited code coverage results from previous runs were used to automatically re-run all relevant tests, bugs could be spotted quickly with minimal effort.
  • Have a good workflow for Test Driven Development. (Today this is fairly awkward)

Similarly Crates.io is a big deal because it allow for large number of small utilities that in most languages would be re-written hundreds of times, because locating and adding dependencies is more costly. To improve confidence in Crates we should focus on improving security:

Image for post
Image for post
  • Some sort of package code review process using volunteers to help package developers write better more secure code. This could be tied to Badges on crates.io displaying a status based on some criteria
  • More Badges! (API coverage, % unsafe, uncovered unsafe %, etc) and the ability to filter on badges when searching.

Steps should be taken to prevent the malicious takeover of popular crates. Such as:

  • Encouraging the use of two factor authentication
  • Sandboxing of builds/tests from other packages. (Possibly using something like miri or cranelift)
  • Some sort of verification that crates uploaded to Crates.io are the same as what is visible in github what reviewers saw. The easiest way to do this might be to have Crates.io pull directly from github/gitlab/etc. This would also make version tracking transparent.

Finally there are several longer term features which would go a long way towards improving maintainability.

  • The ability to “seal” a trait. Meaning that while it is exposed and can be used externally it can only be implemented within the crate that declared it.
  • Detect API incompatible changes at build time so that semantic versioning validated before pushing to crates.io.
  • Clippy for everyone! Instead of merely documenting anti-patterns a developer could write a ‘bad pattern’ for an incorrect way to use their package. This pattern could be checked against callers’ code to generate warnings if the pattern is present.
  • Crater for everyone! When changing a crate, it would be useful to test the new version against all of the dependent crates.
  • Rustfix for everyone! When a function is changed, it is often deprecated with the old version left in place, but implemented by delegating to some newer method. In such cases instead of merely documenting that callers should change to invoke the new method, it would be better if it were marked such that when they ran `cargo fix` implementation of the deprecated method were inlined into their code, automatically fixing their code to call the new method.

If we keep focusing on improving the developer experience, Rust can become the envy of all other languages. 🦀🦀🦀

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store