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.
Today marks Day 1 of my 42-day challenge to learn Rust—with a twist. I’m not approaching this as a blank-slate beginner. I’m bringing along years of C# experience, mental muscle memory from countless LINQ expressions, async/await workflows, and enough IEnumerable
But now? I’m learning a language that doesn’t have a garbage collector, doesn’t throw exceptions the same way, and thinks null is a bad idea.
I’ve spent over a decade writing C# and building solutions on .NET. But for six weeks, we will step outside the managed world of garbage collection and runtime JIT to dive headfirst into Rust—a systems programming language that promises performance, safety, and no nulls.
Over the course of 42 days, we will learn something new about Rust every single day. We will fight the borrow checker. We will make mistakes. And I will blog it all from the perspective of a C# developer trying to make sense of it.
What will happen when you take a C# developer, hand them a curly-brace language that loves safety and hates nulls, and give them six weeks to figure it out?
You will experience a journey filled with rewired brain circuits, redefined mental models, and a newfound respect for the compiler. This will mark the beginning of my 42-day dive into Rust, a daily learning challenge that will push me out of my .NET comfort zone and into a language that promises to be both frustratingly strict and beautifully empowering.
What if you could go back in time and see exactly what your database looked like yesterday, last week, or even last year? Sounds like something out of a sci-fi movie, right?
Well, Temporal Tables in SQL Server let you do exactly that!
Ever wished you could store semi-structured data in your database without dealing with complex table relationships? Good news! SQL Server has native JSON support, and EF Core makes working with JSON columns easier than ever.
Whether you’re handling dynamic configurations, logging data, or flexible user preferences, JSON columns let you mix structured and unstructured data in SQL Server—without creating dozens of extra tables.
Not everything in your database needs a primary key. Sometimes, you just want to query views, stored procedures, or raw SQL results without forcing a unique identifier on them. That’s where Keyless Entity Types in EF Core come in!
If you’ve ever struggled with querying database views, reports, or read-only datasets, this feature is exactly what you need. Let’s dive into what Keyless Entity Types are, when to use them, and how to make them work in EF Core.
Grouping data in Entity Framework Core (EF Core) used to feel a little… clunky. Sometimes, LINQ’s GroupBy() worked beautifully in-memory but got lost in translation when executing SQL queries. You’d write a simple GroupBy(), and EF Core would pull all the data into memory before doing the grouping—not good!
But things are getting smarter and more efficient in recent versions of EF Core! With LINQ GroupBy enhancements, EF Core now translates more grouping operations into optimized SQL queries, saving memory and improving performance.
We’ve all been there—you’re halfway through a multi-step transaction, and boom! 💥 Something fails. You don’t want to roll back everything, just the part that went wrong.
That’s where Transactional Savepoints come in!
Savepoints let you partially roll back transactions, keeping the good stuff while undoing just the problematic parts. If you’ve ever wished for a “Ctrl + Z” in database operations, this is it.
Not all database tables are created equal! Sometimes, you don’t need direct access to raw data—you need a refined, read-only version that makes querying easier. That’s where database views come in!