Rust’s design goals should be about code
Rust has been kicking around the idea of design goals, under various names, for some time. Design goals are useful because they give everyone making product decisions a common language and set of priorities to appeal to. If done well, they would accumulate the design wisdom of Rust into a concise package and assist RFC authors outside the Rust teams themselves.
Last month, in the two days before RustConf, the Lang team held a meetup where I presented a draft set of design goals. These goals are framed differently from what we have tried in the past. Rather than starting from what makes a great language, they are phrased in terms of what makes great code.
I think this is a much better way of framing our goals. Here is a sample revised from the draft:
Correctness by construction
Great code is trivial to verify. It maintains its invariants by making invalid states unrepresentable. It leans on static checks to keep bugs out of the codebase and ease the burden on reviewers.
Clarity of purpose
Great code brings only the important characteristics of your application to your attention. It avoids wading through needless complexity to express an idea. Great code can be written and understood iteratively, emphasizing different characteristics at different levels of abstraction.
Power through composition
Great code is built from smaller building blocks that are easy to understand. It leverages existing libraries where appropriate, composing them in high-level ways to express its aims.
Flexibility to change
Great code has the flexibility to accept changes over time, from a diverse array of contributors, without losing confidence in its correctness.
The point of this framing is to put the experience of our users first. That includes programmers who are not enthusiasts or even Rust users by choice. Working with great code can be a delight for everyone involved, and a great language supports writing great code.
If we do our job right, our users will not wake up every day thinking about the semantics of the language they’re using. They won’t romanticize about the brilliant minds who designed it or how clever the parsing formalism is. That can never be our goal, least of all because it’s not realistic. The best technology fades into the background.
Many of our users will work in rapidly changing codebases that don’t fit in their heads. We want them to solve their problems quickly, predictably, and with confidence. We want them to ship features to their users joyfully and on time, without getting pulled into endless bug hunts.
The elegance of a programming language matters to an extent, but that extent is limited. If we overemphasize it, we can end up missing out on the bigger opportunity in front of us. Building products on great code can be transformative to the engineering teams building them, and ultimately to their end users around the world.