#610 – May 31, 2026
C# 16 is redesigning the unsafe keyword to act as an explicit contract
Improving C# memory safety
about 1 hour by Richard Lander
C# 16 is redesigning the unsafe keyword to act as an explicit contract between callers and API authors, not just a context that enables pointer use. Every unsafe operation must appear inside an unsafe block, and unsafe members must document caller obligations via a new safety comment. The compiler enforces these rules as errors, making unsafe code visible and auditable instead of hidden by convention. The feature arrives as a preview in .NET 11 and a production release in .NET 12.
Stop paying AI agents to play hide-and-seek with your test suite
sponsored by Jetbrains
Claude and Codex are great at writing tests – but terrible at finding them. JetBrains Rider teaches AI agents a new skill that cuts AI expenses by up to 50% while keeping generated tests aligned with your codebase. Curious what the secret sauce is? Their blog has the answer.
State machines in .NET: Modelling Uber's trip lifecycle
11 minutes by Adrian Bailador
Adrian explains how state machines can be used in .NET with EF Core to manage an Uber-like trip lifecycle safely and reliably. He covers trip states, transition rules, concurrency handling, domain events, and timeout management. The design prevents invalid state changes, race conditions, and duplicate actions while keeping the system scalable, maintainable, and fault-tolerant for real-time ride-sharing applications.
ASP.NET, factory patterns, and the illusion of control
7 minutes by Bipin Joshi
Factory patterns in .NET promise cleaner object creation, but often just move complexity elsewhere. The built-in dependency injection container in ASP.NET Core handles this better by distributing responsibility across components instead of centralizing it. Factories still have their place when runtime conditions demand them, but adding them by default makes code harder to read. The most maintainable systems are those easiest to understand, not those most tightly controlled.
Unity events: Why most devs still get them wrong
31 minutes by Darko Tomic
Most Unity devs get C# events wrong in the same handful of ways: they reach for UnityEvent when Action is cleaner, forget the event keyword, wipe out subscribers with = instead of +=, and skip unsubscribing in OnDisable. Darko walks through delegates, Action, the event keyword, UnityEvent, and the subscribe/unsubscribe pattern, using real code from a Unity game he shipped. By the end, you will know which tool to reach for, when, and why.
Why I switched to primary constructors for DI
6 minutes by Milan Jovanović
Milan explains why he adopted primary constructors in C# for dependency injection service classes. Primary constructors reduce boilerplate code, improve readability, and simplify service definitions. He also discusses their use in entities and value objects, while highlighting an important limitation: constructor parameters are mutable unless explicitly assigned to readonly fields.
And the most popular article from the last issue was: