Stability → Productivity → Maintainability

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.

• Cargo is awesome
• Restdoc is great
• Clippy is now stable
• Ide integration and the language server have made huge strides
• Tests, coverage, and benchmarking all come built in

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.

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

• 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:

• 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. 🦀🦀🦀