Match: Switch on Steroids

Match: Switch on Steroids

Welcome to Day 17! By now, we’ve covered some seriously cool Rust features, but today might be my favorite so far: the match expression. If you’re coming from a C# background—especially with the newer C# 8+ switch expressions—you might think you’ve seen it all. Trust me, Rust’s match is like a switch statement on steroids, protein shakes, and a Red Bull chaser.

Enums: Discriminated Unions Done Right

Enums: Discriminated Unions Done Right

Welcome to day 15! Today, we’re diving into Rust’s enums—and spoiler alert—they’re not your typical enums from C#. Rust enums are powerful, flexible, and genuinely fun. If you’ve ever looked longingly at F#’s discriminated unions (or scratched your head at C#’s enums), you’re about to discover something delightful.

Rust Structs vs C# Classes: Less is More

Rust Structs vs C# Classes: Less is More

Welcome back! After wrestling with Rust’s strict ownership rules, let’s ease into something a little more familiar (yet refreshingly different): structs. As a C# developer, you’re probably thinking, “Oh, great, Rust structs are just classes, right?” Well, not exactly. Rust structs offer a minimalist and highly efficient way to structure data, contrasting nicely with our beloved C# Plain Old CLR Objects (POCOs).

Shadowing in Rust: Redeclaring with Style

Shadowing in Rust: Redeclaring with Style

We’ve all been there. You’re coding away, and suddenly you reuse a variable name without realizing it. If you’re a C# developer, your brain probably triggers a warning alarm, screaming something like, “Hey, buddy! You’ve already used that name!” But guess what? In Rust, this isn’t just allowed—it’s encouraged, and it even has a cool name: shadowing.

So what exactly is shadowing, and why does Rust promote it? Let’s dive in and explore how this stylish redeclaration trick differs from what we’re used to in C#.

Slices and Strings: Goodbye C# StringBuilder?

Slices and Strings with Rust: Goodbye C# StringBuilder?

When you’ve spent years writing C#, you get really comfortable with string being immutable, Span being your performance trick, and StringBuilder being your go-to hammer when a for loop starts building text.

And then you start learning Rust.

Suddenly, String isn’t immutable. &str looks suspiciously like a Span in disguise. And you realize… wait, do I even need a StringBuilder anymore?

Today on Day 12, I dove into slices and strings in Rust, and let me tell you, it’s a whole new world, but a surprisingly elegant one.

The Borrow Checker: Rust’s Tough-Love Mentor

The Borrow Checker: Rust’s Tough-Love Mentor

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.

Borrowing and References: Rust’s Version of ref (But Nicer)

Borrowing and References: Rust’s Version of ref (But Nicer)

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.

Move Semantics in Rust: What Just Happened to My Variable?

Move Semantics in Rust: What Just Happened to My Variable?

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.

Ownership, Borrowing, and the Compiler’s Wisdom

Ownership in Rust: The Most C++-ish Thing I’ve Loved (and I Mean That in a Good Way)

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.