Rust, Immutability, and the Comfort of Constants

Rust’s insistence on immutability took me by surprise the first time I used it. As a python dev, I was used to changing variables whenever I wanted, tweaking things on the fly. In Rust, you have to be deliberate, things stay the same unless you go out of your way to make them change. At first, this felt like a hassle , why put up more barriers?

But lately, I’ve found a strange kind of comfort in it. When life feels unpredictable and everything seems to shift, jobs, relationships, even the ground you stand on, there’s something grounding about the rules in Rust. Here, at least, I get to work in a space where certain things really stay put. You can look at a piece of Rust code and trust it, what changes is obvious, what doesn’t is a promise kept. In weeks where not much else feels certain, that clarity is more than just convenient, it’s a small reminder that stability still exists somewhere, even if it’s just on your screen.

The Basics of Immutability in Rust In Rust, every variable you declare is immutable by default. That means once you give something a value, Rust won’t let you change it, unless you explicitly tell it otherwise. let answer = 1; answer = 2; // ^^^ error: cannot assign twice to immutable variable `answer`rus If you’re coming from languages where reassignment is the norm, this can feel awkward at first. But Rust’s immutability isn’t meant to frustrate you , it’s there to make your thinking, and your code, clearer. When you do need to change a value, you have to choose mutability at the very start. Something like: let mut answer = 1; answer = 2; // This is fine now That little extra bit of typing makes a big difference, it forces you to pause and ask, “Do I actually need this to change?”. Most of the time, you’ll find you don’t, and that realisation leads to code that’s simpler, easier to reason about, and much safer to share. Why Immutability Matters At first glance, immutability looks like a constraint. But constraints often force us to be intentional, both in code and in life. When every change must be declared up front, you start to notice just how much needless change happens out of habit. Immutability means less room for accidental bugs, no more silent, unexpected value swaps halfway through a function. It also means anyone reading your code can relax a bit, what you see at the start is what you’ll get throughout. let user_id = 1001; process_user(user_id); // user_id is guaranteed not to change There’s comfort in knowing that what’s important won’t suddenly shift on you, a kind of predictability we don’t always get outside our code editors. Sometimes, the variables that don’t change end up being the foundation you can actually build on. Niche Ways Rust Doubles Down on Immutability Shadowing Variables — But Still Immutable You can “shadow” a variable by re-declaring it, but each shadow is still immutable unless you mark it mut let score = 10; let score = score + 5; // shadows the old score // score = 20; // still immutable Even when you reinvent yourself, Rust prefers you stay true to your word, unless you ask for change. Immutable Struct Fields Struct fields are immutable unless the whole instance is declared mut, and even then, only those fields that aren’t “borrowed” stay editable struct User { id: i32, name: String } let user = User { id: 1, name: String::from("Viraj") }; // user.name = String::from("Not Viraj"); // can't mutate Sometimes, changing one detail requires a bigger commitment , just like in life. Constants: Locked Outside Time Rust constants (const and static) are eternal. They cannot—and will never, change for the program’s entire run: const PI: f64 = 3.1415; // PI = 3.14; // not now, not ever There’s comfort in knowing some values don’t budge, no matter how much the world turns. Pattern Matching Variables are Immutable Variables introduced within match arms are immutable unless marked otherwise: match value {

   1 => { let x = 42; /* x is immutable here */ }
   _ => {}

} Sometimes, the possible outcomes may differ, but your promises for each one remain the same. Immutability in Closures By default, closures capture variables immutably, unless specified with move (and even then, ownership, not mutability, is transferred): let mut num = 1; let add_one = || num + 1; // closures borrow `num` immutably by default You can pass feelings into a conversation, but unless you move them, they remain untouched. The bugs that never occurred When I first started writing concurrent code, I thought I could keep track of every variable’s state on my own. In Python, sharing a simple object between threads worked, until it didn’t. I once spent hours debugging a race condition caused by one thread quietly updating a variable while another thread expected it to stay the same. The result? Subtle, inconsistent behavior that only appeared under load. In Rust, that kind of bug can’t sneak in. Immutable variables can be freely shared between threads because nothing can change them. If you want to mutate shared data, Rust forces you to wrap it in special types like Mutex or Arc(more on this in the coming articles), so you’re always aware when multiple hands are on the same object. use std::thread;

let data = 100; let handle = thread::spawn(move || {

   println!("{}", data); // perfectly safe data that can’t change

}); handle.join().unwrap(); It turns out, the things that can’t change are often the ones you rely on most , especially when you realize you’ve made a bad choice or two along the way. In both code and life, mistakes are inevitable. Sometimes you take a wrong turn, rewrite the same problem twice, or change something you wish you’d left alone. But when your foundations are solid, when certain constants hold, you’re less likely to unravel completely. Immutability won’t save you from every misstep, but it does make course correction easier, you always know exactly where you started, and what you can trust to stay put. I would love to hear about this from you folks, what’s your favourite “unchanging” in code, or in your world outside the keyboard? Have you ever been saved by Rust’s strictness? TL;DR Rust’s immutability keeps your code steady, but life’s “constants” sometimes move anyway. When they do, the bugs hurt more, but with clarity, you find where to rebuild. Refactoring isn’t failure, it’s how you move forward, both in code and in the messier releases life ships you. Hey! Look, you made it to the end 🎉 Thank you for your time!

Read the full article here: https://medium.com/@veer15/rust-immutability-and-the-comfort-of-constants-cea66dc01890