You think you’ve been writing safe code… until you meet the Rust borrow checker.
Then suddenly, your once-proud instincts are being side-eyed by a compiler that’s not mad, just disappointed.
Today, on Day 11 of my Rust journey, we talk about the infamous, unyielding, sometimes infuriating, but ultimately brilliant guardian of Rust safety: the borrow checker.
If you’ve been writing C# for a while, you’ve likely crossed paths with ref, in, and out parameters. They allow you to pass variables by reference, enabling a method to read or modify the original value.
Useful? Definitely.
Safe? Uh… sometimes.
In Rust, there’s a similar concept called borrowing. It uses & and &mut, and it feels a lot like passing ref or in in C#, but with one significant difference:
The compiler enforces safety rules that make data races and invalid access impossible.
Today, we’re diving into borrowing, references, and how Rust holds your hand (and your memory) without letting you write foot-gun code.
Okay, so picture this: you’re cruising along in your nice, type-safe Rust code, and suddenly… your variable vanishes.
Not literally, of course. But the compiler throws a fit, and you’re left staring at an error that says something like:
“value borrowed here after move”.
Wait, move?
Welcome to move semantics, Rust’s very opinionated way of managing memory and keeping you from accidentally using things that don’t belong to you anymore.
Today’s post is a follow-up to yesterday’s crash course in ownership and this one might sting a little at first if you’re coming from the comfy world of .NET’s reference types. But stick with me. It’s about to make sense.
Let’s get one thing out of the way: as a C# developer, I’ve never had to think too hard about memory. The garbage collector (GC) is always there, lurking in the background, sweeping up after my code, like a very polite, very invisible butler.
But Rust? Rust doesn’t do garbage collection. There’s no GC.Collect(), no memory profiler needed to chase leaks from forgotten Dispose() calls. Instead, Rust gives you something bold, powerful, and… at first, kind of intimidating:
Ownership.
Today’s post kicks off Week 2 of my Rust adventure, and it’s all about how this one idea changes everything.
Seven days into learning Rust, and I feel like I’ve been through a developer bootcamp with a compiler that doubles as a personal trainer. It doesn’t let you slack, but it does make you better.
This week, I went from installing the toolchain to wrestling with immutable variables and puzzling over semicolons in return statements. As a C# developer, I expected syntax differences, but I didn’t expect the philosophical shifts.
Let’s recap what stood out, what stung, and why I’m still excited to keep going.
When I first started exploring Rust, one of my instincts was to reach for a class. You know the drill. Need to model some data? Write a class, slap a few properties on it, and maybe add a constructor or two.
But Rust had other plans.
On Day 6, I dug into Rust’s scalar and compound types and quickly realized that Rust doesn’t want you to start with classes. Instead, it hands you a small set of powerful primitives and says, “Let’s build something lean.”
Today’s Rust lesson hit a familiar note but with a twist. Writing functions in Rust feels almost like writing them in C#. Until, of course, the compiler reminds you that this language doesn’t always play by the same rules.
On Day 5 of my Rust-for-C# developers journey, let’s break down function definitions, type inference, return values, and where Rust and C# shake hands… and where they give each other a suspicious side-eye.
On Day 5 of my Rust-for-C# developers journey, let’s break down function definitions, type inference, return values, and where Rust and C# shake hands… and where they give each other a suspicious side-eye.
So today, I ran head-first into a Rust design decision that made me pause and go, “Wait… really?”
In C#, I can declare a variable with var and change it later. No fuss. In Rust? Not so fast. Your variables are frozen solid if you don’t explicitly ask for mutability. Welcome to Day 4: the world of let, mut, and what happens when your muscle memory meets a strict compiler.
Let’s be honest—every new language journey begins the same way: with a humble “Hello, World!” It’s the developer’s rite of passage. So today, on Day 3 of my 42-day Rust challenge, I’m writing the most iconic two-word phrase in programming in both C# and Rust… and then tearing it apart.
Because while the output is the same, what these two languages make you say to get there reveals a lot about how they think.
It’s Day 2 of my journey learning Rust as a longtime C# developer, and today I took the plunge: I installed Rust and created my first project. The whole thing felt a bit like unpacking a new toolbox—familiar enough to recognize the tools, but different enough that I had to check the manual.