Last year for Rust 2018 I didn’t write a post like this, hoping to see other people write it. But even with a hundred plus posts that didn’t happen, so this year it’s the moment to speak up.
I have used many different languages in past and when I started studying Rust at version 1.0 I was quickly impressed by its very good design, I was mostly in agreement with most of its design decisions, despite every useful language has a messy implementation. Even small things were designed with care. And I loved how much Rust cares for code correctness. I prefer to avoid long debug sessions and to use more time in the design and coding phases. So I’ve kept learning and using it ever since.
For 2019 and beyond I’d like Rust to keep working on finishing its many unfinished parts. There are lot of unstable features that should be stabilized or modified (or perhaps even closed for now). Keeping features unstable for several years risks making them more like Haskell Language Extensions. Haskell was born to be a testbed for language research, so having lots of implementation-defined Language Extensions could be acceptable for it, but for a more practical language as Rust having features like “slice_patterns” unstable for years is a problem, in my opinion. I now have a ton of code that uses slice_patterns on Nightly, but I don’t know if and how it will keep working.
Beside those stabilizations of unfinished work, I think it’s important for Rust 2019+ to work on improving on one of its main core values, that is correctness. This means that I’d like Rust to improve how reliable it is for basic computing, that means its usage of integral numbers, arrays, slices, vectors (and perhaps even functions). Those are the foundations for most Rust code. Improving reliability for such things is not easy, and it could go against certain usages of Rust. If you are writing quick and small script-like programs then lot of care for correctness could hinder you. So the features that help code correctness should be optional. Only a small subset of code should be at a medium or high integrity level, but Rust should offer well designed optional features for this use case too.
If you take a look at languages designed for maximum reliability, like Ada-SPARK, Spec#, Why3, ATS2 and so on, you see features like contracts to prove correct (as discussed by RustBelt too). But in practice code correctness comes from many other smaller features too, that should be available. So if Rust wants to develop its correctness and to be useful for high reliability usages too it should also improve on its handling of basic constructs like integral numbers, arrays, slices and vectors. There are many small features to do this.
Despite only a small percentage of Rust code needs to be proven correct, the features of Rust to allow this should be usable by a larger group of people. Rust in my vision could help spread the idea of static verification of code, and in general slowly change how programmers and their bosses think about writing system code, to help them care more about formal code correctness.