---
title: "Thoughts on Rust beliefs"
date: 2024-03-12
tags: ["T-lang", "analysis"]
author: TC
url: https://hackmd.io/ezIsK3_uSkuIq0v7QMLIyw
---

# Thoughts on Rust beliefs

The Rust language is what it is because of a particular set of *beliefs* held by the people who designed it. As we continue to evolve the language, and as we ourselves change over time, there is some risk of us losing these important beliefs and thereby starting to lose what makes Rust unique and appealing. While it might be OK for some beliefs to shift over time, we should do this consciously rather than accidentally.

This suggests that we might want to write down these beliefs, if possible. How might we best do that?

## Goals

The beliefs that we write down should serve two complementary purposes:

One, they should help us understand (and build sympathy for) *why* Rust is the way it is. Without context, the path that Rust takes might seem jagged and haphazard. But looked at through the right lens, we can see Rust moving in a roughly straight line toward ambitious goals. The beliefs we write down should help to focus this lens.

Two, these beliefs should serve us when designing the language. They should be practical. When we are lost, they should guide us to desirable possibilities. When we are feeling uncertain, they should strengthen our resolve to do hard but correct things. When we are at risk of error, they should remind of us of essential caution.

## Uniqueness

We want to capture those beliefs that make Rust *unique*. To do that, the beliefs must *exclude* other languages, both existing and potential. If our beliefs would admit other languages, then our beliefs are probably not specific enough. (Conversely, if our beliefs exclude *Rust* itself in some small ways, those might point to errors in Rust that we might seek where possible to fix.)

Rust was created due to *unhappiness* with the alternatives that then existed. And still today, if we were not unhappy with other options, we might not work on Rust. The beliefs we record should capture this unhappiness.

To turn that around and put it differently, Rust is a *loved* language. We don't love people or things that are commodities. We love people and things that are unique and special. The beliefs must get to the heart of this specialness.

## Kinds of beliefs

There are two kinds of belief statements, for our purposes.

One kind are statements about *outcomes*. We might say, e.g., that we want programs written in Rust to be reliable. That's an *outcome statement*.

The other kind are statements about *mechanisms*. We might believe, e.g., that the use of algebraic data types to encode invariants drives reliability. That's a *mechanism statement*.

In writing out our beliefs, we need to think about how to relate mechanism statements with outcome statements.

## What are we willing to sacrifice?

There's a particular risk with outcome statements: it's easy to write things that could be mistaken for platitudes. We certainly want Rust programs to be reliable, but who wouldn't want their language to result in reliable programs? Few designers would even admit that's not a top priority. This speaks to the limits of such outcome statements, even with ordering, to get at the heart of what makes Rust unique.

One way out of this trap is to focus on mechanisms. The other is to state explicitly what outcomes we're willing to sacrifice. There is some interplay between these.

For example, maybe we believe that local reasoning drives reliability (a mechanism). But by excluding the non-local, we may increase repetition and sacrifice DRY ("don't repeat yourself"). Our beliefs here form something reminiscent of a proof tree:

- Local reasoning drives reliability.
- ...but sacrifices DRY.
- We want reliable programs.
- ...so we need programs about which we can reason locally.
- ...even if that means repeating ourselves.

We could argue that these results are implied by a particular ordering of our outcome statements. However, there's a real risk here that the subtle implications of such ordering may be clear to us as the authors but may not in fact be clear to others or even potentially to our future selves. Given our goals, it may be better for us to write out the various tradeoffs and sacrifices that we're willing to make as plainly as possible.

## The power of mechanism statements

Our beliefs about mechanisms have a particular power in setting Rust apart. We can see already from the two we've mentioned how these separate Rust even from its close siblings.

E.g., our belief in local reasoning separates us from the many MLs that require more global reasoning, while our belief in the effectiveness of algebraic data types separates us from languages like C, C++, Java, JavaScript, Python, the various Lisps and Schemes, etc.

Many of our beliefs about mechanisms are not as widely shared -- and especially were not when we adopted them -- as our beliefs about outcomes might be.

## Adversarial testing: Erlang

To ensure that our encoded beliefs uniquely define Rust, we should test them adversarially against other real or imagined languages. Let's do that here with a solid set of outcome statements that seem quite plausible to this author (thanks to NM for setting these out). Here's the ordered set:

1. Programs written in Rust should be reliable.
2. Programs written in Rust should be performant.
3. Rust should be extensible.
4. Rust should be transparent and tunable.
5. Rust should be accessible.

At one level, these seem roughly right for describing Rust. But let's see if we could also arrive at **Erlang** with these beliefs.

For 1, was *reliability* the top priority in the design of Erlang? Yes, it certainly was. It was designed specifically for the engineering of telephony infrastructure with extreme uptime requirements.

For 2, was Erlang designed to be *performant*? In some sense, it certainly was. It was designed to build systems of immense scale, and it famously enabled WhatsApp to grow to hundreds of millions of users with a tiny staff and infrastructure. From a Rust perspective, we might quibble that it's not meant to crunch numbers without dropping to C code. But the Erlang folks could fairly point out, "hey, remember, reliability was priority number 1, and performance on *our* intended workloads was a key priority for us."

For 3, was Erlang designed to be *extensible*? Yes. It would take up too much space to elaborate the details, but suffice it to say that it is, and that such extensibility is important to Erlang, but less important than reliability and overall system performance.

For 4, was Erlang designed to be *transparent* and *tunable*? Again, without going into details, yes, it has all manner of knobs, and one can always drop down a level to achieve arbitrary ends.

For 5, was Erlang designed to be *accessible*? Again, yes, this was clearly a goal and much has been written about how the designers tried to do this and their experiences with teaching Erlang to others within Ericsson. Was this probably less important than items 1-4? Again, yes.

Maybe we could tweak our wording on item 2 to conclusively exclude Erlang. But even then, the fact that it may plausibly come so close to being accepted by these beliefs should give us pause. While Rust does have some similarities to Erlang (not accidentally), the differences are also enormous. We want our beliefs to make a clear separation here.

## This is hard

We should acknowledge explicitly here that this is just a hard problem and that the beliefs stated above are entirely reasonable. Writing down a set of beliefs that neither "prove too much" nor "prove too little" while being practical and helping to guide future decisions is a hard thing to do. Many people across many eras have struggled with this.

However, hard as it may be, it's important that we do this, and that we do this as well as is possible, so let's explore some ideas for how best to derive our beliefs. We'll give a few possible examples of these, but the main point is to hopefully inspire you, the reader, to come up with many more ideas about the beliefs that define Rust.

## Belief: No runtime

To find the set of our general beliefs, we may need to work backward from some specific beliefs that we unquestionably hold. One such belief is that Rust should have no runtime. A great number of extremely hard problems in the design and implementation of Rust would become much less hard if we were to accept garbage collection or other significant implicit runtime behaviors. We choose not to do that and to tackle the hard problems instead because *that's what Rust is*.

Of course, we do have reasons for this. If Rust were to have a runtime, then it couldn't hope to replace C everywhere that C is used. And while we try politely to not speak of our plans for world domination, we do treat as an invariant that anything that would preclude replacing most modern uses of memory-unsafe systems languages must not be done. This is the essence of a core belief.

This belief that Rust should not have a runtime plausibly dominates most other beliefs. Even if we could make Rust programs more reliable or performant by adding a meaningful runtime, we still probably would not do it.

## Belief: Stability

It's easy to take it for granted, but we have particular beliefs about stability that are not commonly held outside of our ecosystem. We've written some of these particulars down, e.g. in RFC 1122. Still, when enumerating our beliefs, it may be worth writing this one down too, as in practice, our belief in stability can override many other outcomes we might want. Of course, our desire for stability is not unbounded, and we do carefully trade it when needed for other things (e.g. soundness). As with most of our beliefs, it is intertwined with them.

When we're discussing stability, it's worth us also being clear about what kinds of things we *don't* believe in that others might still call stability. This goes beyond the exclusions to our stability guarantee and includes our thinking on e.g. minimum supported Rust versions and the rate and desirability of language evolution.

## Belief: Industrial but advanced, powerful, and principled

We want Rust to be an industrial language. Famously, Haskell has the unofficial motto, "avoid success at all costs". Conversely, Rust has a naked ambition for wide adoption. This too is a belief that is central to what Rust is.

There are, however, some prices that we have not been willing to pay for that.

Some other languages have achieved wide adoption by keeping low their ambitions for advanced language design. It's an entirely valid approach to win by providing a rock solid implementation of only well-trodden and uncontroversial ideas.

Rust has not taken that path. We have embraced an innovative borrow checker, algebraic data types, generics, advanced type inference, closures, expression-orientation (even e.g. for `if`), existential types, macros by example, procedural macros, async/await (in our approach, coroutines in disguise), and much more.

(One story, relayed to the author by Eric Holk, is that the Rust team once flew Dan Grossman, the designer of the Cyclone programming language, out to the Mozilla offices to pick his brain about how we might build an effect/capabilities system into an industrial language, and that the borrow checker was an outcome of that.)

Many language designers, particularly prior to Rust, would have balked at including even just *one* of those powerful features in a language meant for industry. We seem to believe that an industrial language can be *more*.

Relatedly, we tend to look for *principled* solutions to problems. This is an artifact of being willing to accept *general* and *powerful* language mechanisms. A language that is not willing to accept powerful mechanisms has to make do with many special case solutions for various problems. But a language like Rust can adopt something closer to what Guy L Steele wrote in the Scheme reports:

> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

Perhaps we would make some edits or adjustments to this. But judging by our actions, we seem to hold as a belief something to this effect.

## Belief: Two kinds of language power

Rust is a powerful language on two fronts. One is that Rust allows us to precisely control the machine. This is often the first thing people think of when considering the power of a language.

But Rust has another kind of power: our systems for automatic proof checking.

(Indeed, one way to look at much of Rust's evolution is to see it as us having continued to extend our proof checking systems to cover more of the code that people write.)

One of the unique things about Rust is how far we go on both of these fronts. Many languages with powerful proof checking give up on allowing for precise control of the machine, and most languages that allow for precise control of the machine give up on powerful proof checking.

The fact that we choose both here helps explain both why Rust is so particularly difficult to design and implement (and sometimes, unfortunately, to use), and yet it also explains at least one of the reasons why Rust is so loved.

Our willingness to do this hard thing seems to point to some important set of core beliefs that we must hold.

## Your beliefs go here

The purpose of this document is to inspire you, the reader, to think through the *outcome* and *mechanism* beliefs, and the interplay between each of them, that have made Rust what it is and that will continue to drive Rust into the future.

For that purpose, we've given enough examples, so we'll stop here for now.

Please let the author know if you found this framing to be helpful and what ideas this brought to your mind about the *beliefs* that serve as the foundation of Rust.