The reason why the Rust language’s developers can advertise features like thread safety and memory safety guarantee is because of a fundamental design ideology of immutable variables. Immutable variables are the type of variables where, once you assign a value, it does not change.

Rust also has constants. So you might wonder “Why does Rust have Immutable variables and Constants? Aren’t they the same thing?”

In this blog post, I will explain the basics of variables and constants in Rust, and how an immutable variable differs from a mutable variable.

Immutable variables VS Constants Link to heading

If, like me, Rust is not your first programming language, this confusion is bound to occur sooner rather than later–“Why do either immutable variables or constants exist in Rust?”

If you have written a simple program in Rust, you will realize that Rust has 2 types of variables. One is the type which allows changing a value, even after it is assigned, called mutable variables. The second type is the one in question, immutable variables. Unless explicitly specified, Rust assumes a variable is immutable. Meaning, once a value is assigned to your variable, that value will never be allowed to be changed.

Rust only has one type for constants. The one which makes sense. Immutable by default. Once a value is assigned, it is not allowed to change.

Type inferencing Link to heading

When you declare a variable in Rust, you do it using the let keyword. This is different than other low-level languages like C and C++, where you are to explicitly specify the data-type of a variable using the appropriate keyword like, int, float, char, etc.

Using the let keyword is necessary, but specifying a variable’s data-type is not necessary. You can either leave it to the Rust compiler (rustc) to take a guess–which hardly misfires–or you can annotate the type yourself.

This guessing that rustc does is called “type inferencing”.

Type inferencing is absent for constants. It is the job of a programmer to provide a type for a constant that is declared.

Take a look at the following code:


fn main() {
    let my_var = -128;
    const MY_CONST = -128;

In here, I am declaring an immutable variable (my_var) with the value “-128” and a constant (MY_CONST) with the same value of “-128”. Another similarity is that neither of them are type annotated.

Let’s try and compile this.

$ rustc
error: missing type for `const` item
3 |     const MY_CONST = -128;
  |           ^^^^^^^^ help: provide a type for the constant: `MY_CONST: i32`

error: aborting due to previous error


rustc is complaining about an error on line 3 (where we declared our constant). The highlighted part is the name (MY_CONST).

The help states “provide a type for the constant”. The help message also included a “recommended/suggested type” (i32) but it was not applied.

Hence, one of the difference between an immutable variable and a constant in Rust is that constants need type annotation. Type inferencing is not applicable to constants.

Scope of declaration Link to heading

Another point of difference between an immutable variable and a constant in Rust is its scope of declaration.

Constants can be declared globally (before/outside the main function). Variables, immutable or otherwise, cannot be declared globally.

Let’s see this with an example.


const MY_CONST:i32 = -128;
let my_var: i32 = -128;

fn main() {
    println!("{my_var} {MY_CONST}");

As you can see here, I have mostly the same code as above, but I have moved both, the variable and the constant declaration, in the global scope.

’tis compile time!

$ rustc
error: expected item, found keyword `let`
2 | let my_var: i32 = -128;
  | ^^^ expected item

error: aborting due to previous error

An error :(

The way I wrote the code should give you a hint. We have an error on the 2nd line. Our constant is declared on the 1st line.

This means, rustc did not see any problems with a constant in the global scope. But it does have a problem with our immutable variable if it is declared in the global scope.

Assignable values Link to heading

Another major difference between variables (immutable or otherwise) and constants in Rust is that a constant cannot have a value that can be calculated only at run-time.

What do I mean by this?

Take a look at the following code:


fn main() {
    let pi: f32 = 3.14;
    const PI_TIMES_TWO: f32 = pi * 2;

In this code, I am declaring an immutable variable (pi) and assigning it the value of “3.14”. Next, I declare a constant, with the same type as pi, and I assign it the value of pi * 2.

Shall we compile?

$ rustc
error[E0435]: attempt to use a non-constant value in a constant
3 |     const PI_TIMES_TWO: f32 = pi * 2;
  |     ------------------        ^^ non-constant value
  |     |
  |     help: consider using `let` instead of `const`: `let PI_TIMES_TWO`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0435`.

As you can see, even though pi is an immutable variable, we get this error. This is because PI_TIMES_TWO is dependent on the value stored in pi to determine its own value. This is problematic because the values of variables are not evaluated at compile-time.

The value assigned to a constant must not be calculated/evaluated at run-time.

Compile-time vs Run-time Link to heading

As I just proved, constants can not be assigned a value that will be calculated at run-time. That must raise a question if the core reason for the existence of immutable variables and constants must be related to the differences in run-time and compile-time.

While I am not someone who has contributed to the design of the Rust language, I am inclined to assume that this might be the reason.

You can use the value assigned to a constant during compile-time, to make decisions while the code is being compiled. This can not be done using variables, immutable or otherwise.

Let me demonstrate this using an example.


fn main() {
    let arr_len_var: usize = 5;
    const ARR_LEN_CONST: usize = 5;

    let arr_from_const: [i32; ARR_LEN_CONST];
    let arr_from_var: [i32; arr_len_var];

In this example, I am doing the following:

  1. Declare an immutable variable with the value “5”.
  2. Declare a constant with the value “5”.
  3. Create an empty array, using the value of an immutable variable as the “array size/length”.
  4. Create another empty array, using the value of a constant as the “array size/length”

If, the jibberish that I just wrote above is correct, we should expect a compilation error on the 6th line.

$ rustc
error[E0435]: attempt to use a non-constant value in a constant
2 |     let arr_len_var: usize = 5;
  |     --------------- help: consider using `const` instead of `let`: `const arr_len_var`
6 |     let arr_from_var: [i32; arr_len_var];
  |                             ^^^^^^^^^^^ non-constant value

error: aborting due to previous error

For more information about this error, try `rustc --explain E0435`.

As expected.

rustc has 2 messages for us. The first message–after looking at the 6th line–is a suggestion for us; to change arr_len_var from a variable to a constant.

The second message is an error message. It is complaining that the value which determines the length of an array, is a “non-constant value”.

“But I thought the values of immutable variables could never change?! Does that not equate to a non-constant value?”

You are correct, but this is something different. You see–this is where I am applying my knowledge of what I learnt about compiler design from my college–constants are also evaluated at compile-time.

This means, the following line -

    const PI: f32 = 3.14;

gets replaced with the following in the first few passes of the Rust compiler.

    const PI: f32 = 3.14;

The constant got evaluated (expanded), at compile-time. This will not be be the case for a variable, immutable or otherwise.

This is also what happens when we use a constant to determine the length/size of an array.

Shadows Link to heading

You might know about shadowing in Rust. It refers to the act of referring to a different storage/address using the same name.

Below is an example of shadowing:

let five = 5;
let five = 6;

Here, on the first line, we are declaring an immutable variable five. It assigned the value “5”. In the immediate next line, we declare the variable five again. This time, we assign it “6”.

What this does is, when five was first declared and assigned the value “5”, it was given a memory address to store that “5” which we assigned to it. Assume this memory address to be 0x01.

Then, when we declared five again; this time with a different value, “6”; a different memory address was given to our variable five. This, new memory address stored the value “6”. Assume this memory address to be 0x02.

Now, the older memory address (0x01) is not overwritten with “6”, instead of “5”. It is still kept–maybe because this shadow was a local change and we will need the previous value again? who knows–intact. But now, when we ask, “Hey five, what is your assigned value?”, it will check the memory location 0x02 and give us a value from there; which is “6”.

This isn’t possible for constants.

  • You can not shadow a constant with a constant (of any type).
  • You can not shadow a constant with a variable (of any type).
  • You can not shadow a variable with a constant (of any type).

Minor nit-picks Link to heading

A few minor differences between a constant and an immutable variable are as follows:

  • Variables are immutable by default, but they can also be mutable, if asked nicely. On the contrary, constants are always immutable. (You cannot use the keyword mut next to the const keyword.)
  • To declare a constant, we use the const keyword, but to declare an immutable variable, we use the let keyword. A variable can be made immutable if, at the time of declaration, the mut keyword is used alongside the let keyword.

Conclusion Link to heading

The intelligent mind who were designing the Rust language were obviously not out of their minds when they created variables that default to immutability when constants would also exist.

To recap, constants need type annotations, but they can be declared in the global scope; values assigned to constants cannot be something that is calculated at run-time and they can not be shadowed.