DEV Community: JKC

Your Sum Depends on the Order. Math.sumPrecise() Doesn't.

JKC — Mon, 12 Oct 2026 11:02:22 +0000

TL;DR: Math.sumPrecise() adds up an iterable of numbers without the rounding errors that pile up in a reduce() loop. Same numbers in, same answer out, whatever the order, and it has been Baseline since April 2026.

The total that changed when you sorted the table

Here is a shopping cart:

const cart = [
  { name: "Mechanical keyboard", price: 19.99 },
  { name: "USB-C cable", price: 4.95 },
  { name: "Sticker", price: 0.1 },
  { name: "Mouse pad", price: 12.5 },
  { name: "Sticker", price: 0.2 },
  { name: "Cable ties", price: 7.35 },
  { name: "Sticker", price: 0.3 },
  { name: "Screen wipes", price: 3.15 },
];

const total = (list) => list.reduce((sum, item) => sum + item.price, 0);
const byPrice = cart.toSorted((a, b) => a.price - b.price);

total(cart);    // 48.54
total(byPrice); // 48.53999999999999

Same eight items. Someone clicked "sort by price", and the total moved.

Addition is supposed to be commutative. Floating point addition is commutative for two numbers, but a long chain of them is not associative. Every + rounds its result to the nearest 64-bit float, and those little roundings land differently depending on the order.

It gets worse with big and small numbers together:

[1e20, 0.1, -1e20].reduce((a, b) => a + b, 0); // 0

1e20 + 0.1 rounds straight back to 1e20. The 0.1 is gone before -1e20 arrives. Your dime fell into the couch.

Meet Math.sumPrecise()

Math.sumPrecise(numbers)

It takes one iterable of numbers and returns their sum. The spec asks for the exact mathematical sum of the inputs, rounded to a float only once, at the very end. No intermediate rounding, so order can't matter.

Math.sumPrecise([1e20, 0.1, -1e20]);   // 0.1
Math.sumPrecise([0.1, 0.2, 0.3]);      // 0.6
Math.sumPrecise([0.3, 0.2, 0.1]);      // 0.6
Math.sumPrecise(Array(10).fill(0.1));  // 1

Compare that with the loop:

const naive = (a) => a.reduce((x, y) => x + y, 0);

naive([0.1, 0.2, 0.3]);       // 0.6000000000000001
naive([0.3, 0.2, 0.1]);       // 0.6
naive(Array(10).fill(0.1));   // 0.9999999999999999
naive(Array(1000).fill(0.1)); // 99.9999999999986

Math.sumPrecise(Array(1000).fill(0.1)) gives 100. The loop is off in the 12th digit after only a thousand additions.

Every value above comes from running the code in Chromium 152.

The cart, fixed

const totalPrecise = (list) => Math.sumPrecise(list.map((item) => item.price));

totalPrecise(cart);    // 48.54
totalPrecise(byPrice); // 48.54

Sort by price, by name, or shuffle it. The total stays put.

It accepts any iterable, not only arrays, so it slots into code that never builds an array at all:

const scores = new Map([["ana", 0.1], ["ben", 0.2], ["cy", 0.7]]);
Math.sumPrecise(scores.values()); // 1

function* readings() {
  yield 0.1;
  yield 0.2;
  yield 0.7;
}
Math.sumPrecise(readings()); // 1

It also survives overflow in the middle of the sum:

naive([1e308, 1e308, -1e308]);           // Infinity
Math.sumPrecise([1e308, 1e308, -1e308]); // 1e+308

The loop overflows to Infinity halfway through and never comes back. sumPrecise only cares where the sum ends up.

And no, it isn't slow. In a quick test in Chromium 152, summing a million random numbers took about 4ms with Math.sumPrecise() and about 16ms with reduce(). That's one machine, so measure your own hot paths.

Can I use it?

In browsers, yes:

Firefox 137
Safari 26.2
Chrome and Edge 147, which made it Baseline Newly available in April 2026

Node.js is the catch. MDN's compat data lists no Node version yet, and typeof Math.sumPrecise is "undefined" in Node 24.11. For code that runs on the server or in older browsers, feature-detect it, or use the core-js or es-shims polyfills that MDN links to.

const sum = (numbers) =>
  typeof Math.sumPrecise === "function"
    ? Math.sumPrecise(numbers)
    : [...numbers].reduce((a, b) => a + b, 0);

The fallback is the old, order-sensitive behavior, so don't promise users exact totals on it.

Gotchas

1. It can't fix 0.1 + 0.2. Math.sumPrecise([0.1, 0.2]) is still 0.30000000000000004. The literal 0.1 was never exactly one tenth to begin with, and that float sum rounds to the same answer either way. sumPrecise removes the error from adding, not the error from storing.

2. Strings are a TypeError, not a coercion. Unlike Math.max(), it refuses anything that isn't a number:

Math.sumPrecise(["1", 2]);
// TypeError: Type of 'Iterator value' must be 'number', found 'string'

Values from form inputs, CSV files, or dataset attributes need Number() first. null and BigInt get the same treatment. Honestly, that's a feature.

3. It wants one iterable, not spread arguments. Math.sumPrecise(1, 2, 3) throws TypeError: [object Number] is not iterable. Muscle memory from Math.max(...list) will bite here. The proposal chose this on purpose: spreading a huge list into arguments can blow the stack.

4. The empty sum is -0. Object.is(Math.sumPrecise([]), -0) is true. It prints as 0 and compares equal to 0, so you'll rarely notice, until something checks with Object.is().

5. Infinity and NaN behave like normal math. [Infinity, 1] sums to Infinity, while [Infinity, -Infinity] and anything containing NaN give NaN.

6. Money still wants integers. sumPrecise makes float sums correct and stable. If you're storing currency, integer cents (or BigInt) are still the real fix.

Wrap-up

Math.sumPrecise() is the sum you thought reduce() was giving you. Go find the reduce((a, b) => a + b, 0) in your codebase and give it a proper name.

Sources

This article was written with the help of AI and checked against the sources above.

Stop Setting Flags to Escape Nested Loops. C# 15 Has Labeled break

JKC — Sun, 11 Oct 2026 13:43:33 +0000

TL;DR: In C# 15, break and continue can name an outer loop: break search;, continue orders;. It ships with .NET 11, which is at Release Candidate 1 right now: go-live licensed, but not final yet.

The flag nobody wants to own

You need to find one value in a grid and stop. Simple, right?

int[][] grid = [[1, 2, 3], [4, 42, 6], [7, 8, 9]];
(int Row, int Col)? hit = null;

bool found = false;
for (int r = 0; r < grid.Length; r++)
{
    for (int c = 0; c < grid[r].Length; c++)
    {
        if (grid[r][c] == 42)
        {
            hit = (r, c);
            found = true;
            break;
        }
    }

    if (found)
        break;
}

A plain break only leaves the innermost loop. So you invent a bool, set it, break, check it, break again. Add a third loop and you check it twice.

The other classic exit is goto. It works. It also makes your code reviewer reach for coffee.

Meet labeled break and continue

Put a label on the loop. Then name it when you jump. Same grid, no flag:

search: for (int r = 0; r < grid.Length; r++)
{
    for (int c = 0; c < grid[r].Length; c++)
    {
        if (grid[r][c] == 42)
        {
            hit = (r, c);
            break search;
        }
    }
}

break search; leaves the loop labeled search, and execution carries on after it. continue search; would skip to the next iteration of that loop instead. Both versions above printed (1, 1) for the same grid when I ran them on the .NET 11 RC1 SDK.

If you have written Java, JavaScript, Go, Rust, Kotlin or Swift, this will feel familiar. C# just took a couple of decades to join the party.

Unlabeled break and continue work exactly as before.

A realistic one: importing orders

Here is an import loop with two rules:

A line with no SKU makes the whole order bad, so skip to the next order.
A negative quantity means the file itself is broken, so stop the import.

One label handles both:

var orders = new[]
{
    new Order(1001, [new("SKU-1", 2), new("SKU-2", 1)]),
    new Order(1002, [new("SKU-3", 1), new("", 4), new("SKU-4", 1)]),
    new Order(1003, [new("SKU-5", 0)]),
    new Order(1004, [new("SKU-6", -1), new("SKU-7", 3)]),
    new Order(1005, [new("SKU-8", 1)]),
};

var accepted = new List<int>();

orders: foreach (var order in orders)
{
    foreach (var line in order.Lines)
    {
        if (line.Sku == "")
        {
            Console.WriteLine($"Order {order.Id}: missing SKU, skipping order");
            continue orders;
        }

        if (line.Quantity < 0)
        {
            Console.WriteLine($"Order {order.Id}: negative quantity, stopping import");
            break orders;
        }
    }

    accepted.Add(order.Id);
}

Console.WriteLine($"Accepted: {string.Join(", ", accepted)}");

record Line(string Sku, int Quantity);
record Order(int Id, Line[] Lines);

Output from the run:

Order 1002: missing SKU, skipping order
Order 1004: negative quantity, stopping import
Accepted: 1001, 1003

Order 1002 never reaches accepted.Add, because continue orders jumps straight to the next order. Order 1005 is never even looked at, because break orders ended the whole thing. With goto you would need two labels in two different places for this.

Bonus: leaving a loop from inside a switch

This one has bitten everybody once. Inside a switch, break ends the switch, not the loop around it. Now you can say which one you mean:

string[] commands = ["add", "add", "quit", "add"];
int added = 0;

loop: foreach (var cmd in commands)
{
    switch (cmd)
    {
        case "add": added++; break;
        case "quit": break loop;
    }
}

Console.WriteLine($"Added: {added}"); // Added: 2

Can I use it?

Labeled break and continue are part of C# 15. On the .NET 11 RC1 SDK, #error version reports Language version: 15.0 with no LangVersion set, so there is nothing to switch on.
.NET 11 RC1 shipped on September 8, 2026 with a go-live support license, so it is allowed in production. It is still a release candidate, though, not the final release.
On the .NET 10 SDK (C# 14), the same code fails with CS8652: The feature 'labeled break and continue' is currently in Preview and *unsupported*.

I ran every snippet here as a file-based app with dotnet run file.cs on SDK 11.0.100-rc.1.

Gotchas

1. The label must sit directly on a loop or a switch. Labeling a block and breaking out of it does not work:

block:
{
    for (int i = 0; i < 3; i++) { break block; }
}
// error CS9393: No enclosing loop or switch statement with the label 'block' out of which to break

2. continue only targets loops. You can break a labeled switch, but continue sw; on one gives CS9394: No enclosing loop with the label 'sw' out of which to continue.

3. Stacked labels: only the closest one counts. In a: b: while (true) { break a; }, the loop is labeled b, not a. The compiler answers with CS9393 again. One loop, one name.

4. It cannot escape a lambda. A break outer; inside an Action that sits in the loop gives CS1632: Control cannot leave the body of an anonymous method or lambda expression. A lambda is its own function, so the outer loop is not "enclosing" anymore.

5. finally still runs. A labeled jump out of a try block runs the finally on the way out, just like a normal break. In my test, break outer from inside a try printed finally ran for i=0 and then left both loops.

6. Your IDE will start nagging. The new style rule IDE0410, "Use labeled jump statement", flags the bool flag and goto patterns and offers the labeled version. Turn it off with csharp_style_prefer_labeled_jump_statements = false if you are not ready for that conversation.

Wrap-up

Sometimes the right fix is still pulling the loops into a method and using return. But when the nested loop really belongs where it is, a label says exactly what you mean. Go find that bool found = false; in your codebase and give it a well-earned retirement.

Sources

This article was written with the help of AI and checked against the sources above.

Stop Doing Algebra in clamp(). CSS progress() Is Here

JKC — Sat, 10 Oct 2026 08:14:18 +0000

TL;DR: progress() turns any value into a number between 0 and 1. That makes fluid type and spacing readable, and since September 2026 it works in every major browser.

The line nobody wants to touch

Every codebase has one:

h1 {
  /* 1rem at 360px, 2rem at 1280px. Trust me. */
  font-size: clamp(1rem, 0.6087rem + 1.7391vw, 2rem);
}

It works. It also looks like a lottery ticket.

Where did 0.6087rem come from? A fluid type calculator, in a tab that closed years ago.

Now your designer moves the breakpoint to 1440px. Time to redo the algebra.

Meet progress()

progress() answers one question: how far along is this value, between a start and an end?

progress(<value>, <start>, <end>)

Under the hood it is (value - start) / (end - start), clamped to the range 0 to 1.

.demo {
  opacity: progress(5, 0, 10); /* 0.5 */
  scale: progress(15, 0, 10); /* 1, not 1.5. It clamps. */
}

Think of it as a progress bar for any CSS value. The fun part: the arguments can be lengths.

progress(100vw, 360px, 1280px) is 0 on a 360px screen, 1 at 1280px and up, and slides smoothly in between.

The same heading, minus the homework

h1 {
  /* 1rem, plus up to 1rem more between 360px and 1280px */
  font-size: calc(1rem + 1rem * progress(100vw, 360px, 1280px));
}

The breakpoints are in the code. The sizes are in the code. No slope, no intercept, and no clamp(), because progress() already clamps.

Designer moves the breakpoint to 1440px? Change 1280px to 1440px. Done.

I tested both versions in Chrome 154 at viewport widths from 320px to 1600px. They match, except the hand-rounded clamp() gives 31.9997px at 1280px, while progress() gives a clean 32px. Small win, but I'll take it.

Need several things to grow together? Name the ratio once:

:root {
  --fluid: progress(100vw, 360px, 1280px);
}

h1 {
  font-size: calc(1rem + 1rem * var(--fluid));
}

.section {
  padding-block: calc(2rem + 4rem * var(--fluid));
}

Keep a rem in the base, like the 1rem + above, so text still respects the reader's font size setting.

Cards that size themselves by their container

The viewport is not always the right ruler. A card in a sidebar should not act like it owns the whole screen. Container query units work as inputs too:

<div class="card-slot">
  <article class="card">
    <h2 class="card__title">Release notes</h2>
    <p>Everything that shipped this week.</p>
  </article>
</div>

.card-slot {
  container-type: inline-size;
}

.card {
  /* 0 when the slot is 280px or narrower, 1 at 560px or wider */
  --size: progress(100cqi, 280px, 560px);

  padding: calc(0.75rem + 0.75rem * var(--size));
  border-radius: calc(6px + 6px * var(--size));
}

.card__title {
  font-size: calc(1.125rem + 0.375rem * var(--size));
}

What Chrome 154 actually computed:

Slot width	Padding	Radius	Title
200px	12px	6px	18px
420px	18px	9px	21px
900px	24px	12px	24px

Notice the wrapper. Container query units resolve against the nearest ancestor container, so the card can't measure itself. Somebody else has to hold the tape measure.

Can I use it?

Yes:

Chrome and Edge 138
Safari 26
Firefox 155, which shipped in September 2026 and made progress() Baseline Newly available

Older browsers won't have it, so keep a fallback (gotcha 5 shows the right way).

Gotchas

1. It returns a number, not a length. progress() gives you something like 0.4. Multiply it by a unit inside calc().

2. Don't mix types. progress(3em, 0px, 100px) is fine, since both are lengths. progress(3s, 0px, 100px) is invalid, and the browser throws out the whole declaration. Seconds and pixels are not friends.

3. Same start and end? No explosion. progress(5, 5, 5) is 0, not a divide-by-zero meltdown. The spec says so.

4. no-clamp isn't in Chrome yet. progress(no-clamp 15, 0, 10) should give 1.5. Firefox 155 and Safari 27 support it, Chrome 154 doesn't, so skip it in production for now.

5. The custom property fallback trap. This fallback works, because older browsers drop the second line while parsing:

h1 {
  font-size: 1.5rem;
  font-size: calc(1rem + 1rem * progress(100vw, 360px, 1280px));
}

This one quietly doesn't:

h1 {
  font-size: 1.5rem;
  font-size: calc(1rem + 1rem * var(--fluid));
}

With var(), the browser accepts the line at parse time, so 1.5rem has already lost. When --fluid later turns out to be gibberish to an old browser, font-size falls back to its inherited or initial value, not to your fallback. I checked this by swapping progress() for a made-up function: the plain fallback held at 20px, while the var() version shrank to the parent's 10px.

Fix it with a feature query:

.card {
  padding: 1rem;
}

@supports (padding: calc(1px * progress(1, 0, 2))) {
  .card {
    --size: progress(100cqi, 280px, 560px);
    padding: calc(0.75rem + 0.75rem * var(--size));
  }
}

Wrap-up

progress() lets your CSS say what you meant: this value, between these two sizes. Go find the clamp() line in your codebase that nobody dares to touch. Today's the day.

Sources

This article was written with the help of AI and checked against the sources above.

An Official Claude SDK for .NET? Yes, Really.

JKC — Wed, 27 May 2026 13:39:12 +0000

If you've been building with Claude in .NET, you've probably leaned on one of the lovely community SDKs Anthropic.SDK by tghamm, or tryAGI.Anthropic by the tryAGI folks. Both have carried the .NET community for a long time, and they're genuinely good libraries written by people who care.

So this post isn't really about replacing them. It's about a quiet, kind of nice piece of news: Anthropic shipped an official C# SDK, and the .NET ecosystem now has a first-party option to sit alongside the community ones.

What was released

The new SDK lives at anthropics/anthropic-sdk-csharp on GitHub, and it ships as the Anthropic package on NuGet. You can find the docs at platform.claude.com/docs/en/api/sdks/csharp.

A few things worth knowing up front:

It targets .NET Standard 2.0+, so it works with pretty much any reasonably modern .NET project, including older .NET Framework apps.
It's currently in beta, even though the version number is high. Breaking changes can land in minor releases for now, so it's worth pinning your version if you try it out.
It joins the official lineup alongside Python, TypeScript, Java, Go, Ruby, PHP, and the CLI.

A small "hello, Claude"

Here's about as simple as it gets:

dotnet add package Anthropic

using System;
using Anthropic;
using Anthropic.Models.Messages;

AnthropicClient client = new();

MessageCreateParams parameters = new()
{
    MaxTokens = 1024,
    Messages =
    [
        new()
        {
            Role = Role.User,
            Content = "Hello, Claude",
        },
    ],
    Model = "claude-opus-4-7",
};

var message = await client.Messages.CreateAsync(parameters);
Console.WriteLine(message);

By default it picks up your API key from the ANTHROPIC_API_KEY environment variable, which is a small kindness when you're just exploring.

It uses collection expressions and target-typed new(), which makes it feel like it was written for C# rather than translated into it. A small thing, but a nice one.

A gentle note on the version number

The first official release is version 10, which might look a little surprising.

The story is sweet, honestly. The Anthropic package name on NuGet was already in use by the tryAGI community SDK, which had been shipping versions 1.x through 3.x for some time. When Anthropic wanted to publish an official package, the tryAGI maintainers kindly moved their library over to tryAGI.Anthropic to make room. The official package picked up at version 10 to avoid confusing anyone who already had the older versions installed.

If you were using the Anthropic package previously and something feels off after an update, you probably want to point your project at tryAGI.Anthropic instead. Nothing is broken the package just has a new home.

Should you switch?

Honestly? Take your time. There's no rush.

If you're using Anthropic.SDK by tghamm, you're in good hands. It has been around a while, it supports Vertex AI authentication, helpful patterns for extended thinking, and a lot of thoughtful touches built up over many releases. If it's working for you, it will keep working for you.

If you're using tryAGI.Anthropic, the same applies. It's still maintained, still useful, and the migration path is clear if you decide to move later.

If you have a hand-rolled HttpClient wrapper, the official SDK might be worth a look just because it handles streaming, batching, prompt caching, and tool use out of the box, which can save you from re-inventing pieces you don't really want to maintain.

The honest framing is: this is a new option, not a replacement. The community SDKs got the .NET ecosystem to where it is today, and they're still excellent choices.

Why this is quietly a big deal

For teams in regulated or enterprise environments, having a first-party SDK can make conversations easier with security reviewers, with procurement, with internal architecture groups. It opens a door that was sometimes a little harder to walk through before.

It also means that as new Claude API features land, .NET developers get them on a similar timeline to other languages, which is a nice place to be.

A small thank-you

If you maintain or contribute to one of the community SDKs Taylor (tghamm), the tryAGI team, and everyone who's filed issues or pull requests thank you. You built the bridge that got us here, and a lot of working .NET + Claude apps exist because of your work.

If you want to try the new official SDK, give it a gentle test drive on a small project first. And whichever one you land on, it's a nicer time to be a .NET developer building with Claude than it was a year ago.

💎 .NET 9 Hidden Gems: 7 Power Features Most Developers Are Missing

JKC — Sat, 16 Aug 2025 04:02:46 +0000

.NET 9 has been out for almost a year now, but most developers are still using it like .NET 8.

The real gains aren't in the headline features. They're in the overlooked improvements that solve daily friction.

The Hidden Arsenal

SearchValues for Strings
.NET 8 had SearchValues for chars. .NET 9 etends it to strings with SIMD optimizations.

 private static readonly SearchValues<string> BadWords = 
     SearchValues.Create(["spam", "scam"], StringComparison.OrdinalIgnoreCase);

 public static bool ContainsSuspiciousContent(string message) =>
     message.AsSpan().ContainsAny(BadWords);

Task.WhenEach for Async Processing
Process async operations as they complete instead of waiting for all.

 var tasks = urls.Select(url => httpClient.GetStringAsync(url));

 await foreach (var task in Task.WhenEach(tasks))
 {
     var result = await task;
     ProcessImmediately(result);
 }

UnsafeAccessor with Generics
.NET 8 introduced UnsafeAccessor. .NET 9 adds generic support for zerooverhead private access.

[UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_value")]
public etern static ref T GetPrivateField<T>(Cache<T> cache);

// In tests: direct access without reflection overhead
ref var field = ref GetPrivateField(cache);

Frozen Collections for Performance
Read-optimized collections that are 40% faster for lookups.

private static readonly FrozenSet<string> ValidEtensions = 
     new[] { ".jpg", ".png", ".pdf" }.ToFrozenSet();

public static bool IsValidFile(string filename) =>
     ValidEtensions.Contains(Path.GetEtension(filename));

DATAS Garbage Collection
Dynamic adaptation is now enabled by default. Your GC automatically adjusts heap size based on workload. No code changes needed.

Why This Matters

These features solve specific performance and productivity pain points that add up over time.

Multi-string search becomes efficient. Async coordination gets simpler. Testing private members becomes fast. Collection lookups get faster. Memory management becomes smarter.

The Reality

Most teams ship .NET 9 apps that perform like .NET 6 because they stick to old patterns.

The developers using these features are already building faster systems while others struggle with familiar bottlenecks.

Final Thought

I've been running .NET 9 in production for months now, and honestly, I can't go back.

When I see 20-30% faster response times and better memory usage, sticking with older versions feels like driving with the parking brake on. The performance gains aren't just nice to have anymore, they're real money left on the table."

👾 GPT 5 is coming and it might be smarter than Sam Altman

JKC — Thu, 10 Jul 2025 14:49:04 +0000

GPT-5 is Coming: The AI Revolution You're Not Ready For

GPT-5 is launching soon. OpenAI is aiming for a release between July and September 2025, and it will be free to use.

Sam Altman, the CEO of OpenAI, recently said that GPT-5 may already be smarter than he is. That's not a marketing line, it's a clear signal that AI is entering a new phase.

What's Different This Time

You won't need to choose between models anymore. GPT-5 is built as a single, unified system that adapts to whatever task you give it. Whether you're coding, writing, researching, or creating content, it just works.

It now reasons by default. You don't have to prompt it to think through steps—it already does.

It also remembers. GPT-5 learns your tone, your goals, and your working style across sessions.

You can talk to it, upload images or files, and it understands everything in one conversation. And thanks to its epanded memory, it can handle huge amounts of contet—full books, long chats, or entire project documents.

The biggest shift might be that GPT-5 doesn't just wait for instructions. It takes initiative based on what it sees and what you need.

Why This Matters

For developers, GPT-5 can write production-ready code, fi bugs, and even help design systems. You'll get work done faster, with fewer manual steps.

For founders, it can act like a partner—helping with strategy, marketing, and eecution without needing a full team.

For creators, the content pipeline becomes much smoother. You bring the idea, and GPT-5 helps shape everything else around it.

How It Stands Out

Other models like Claude, Gemini, and Grok each have strengths. Claude is great at research. Gemini does well with visuals. Grok is strong on live social data.

GPT-5 is aiming to do all of it. One model, one interface, full capability, grow the most.

Final Thought

GPT-5 is not just another release. It's a shift in how we'll build, create, and work moving forward.

The question is no longer if it will change everything.

The real question is how fast you're ready to move.

5 Best New Features in .NET 9 & 10 That Every Developer Should Know

JKC — Thu, 12 Jun 2025 15:37:30 +0000

Introduction

I’ve worked with nearly every .NET version in real-world projects, and every major release brings something that either surprises me or genuinely boosts my productivity. With .NET 9 and .NET 10, Microsoft has really stepped up their game these aren’t just incremental updates, but feature drops that can change how you architect and ship your software. If you’re maintaining legacy APIs or jumping into greenfield cloud apps, there’s plenty to get excited about. Here’s a quick rundown of the five features that made me stop, dig in, and say “wow, this is going to save time.
Explore the official release notes:
.NET 9 What's New
.NET 10 What's New

1. Native AOT (Ahead-of-Time Compilation) for All App Types

One of the pain points I’ve run into especially with microservices or background tasks is startup lag and heavy memory usage. Native AOT changes the rules. Now, you can compile your .NET code straight to native binaries, meaning apps launch instantly, use less memory, and don’t drag the entire .NET runtime along for the ride. This is especially huge for anyone pushing containers or building serverless functions.

How to enable Native AOT in your project:

<PropertyGroup>
  <PublishAot>true</PublishAot>
</PropertyGroup>

Publish your app as a native executable:

dotnet publish -c Release -r win-x64 --self-contained -p:PublishAot=true

2. Built-in OpenTelemetry and Observability

Tracing and monitoring used to mean fighting with extra NuGet packages or gluing together logging libraries. With .NET 9/10, OpenTelemetry is built right in. The first time I saw distributed tracing flow from ASP.NET Core through my data layer without much config, I was honestly relieved.

Benefits:

Automatic tracing and metrics
Easier integration with popular monitoring tools
Better visibility into distributed systems

3. C# 13: Primary Constructors and More

I’m a huge fan of anything that helps me write less boilerplate and keeps code clean. C# 13’s Primary Constructors for classes do exactly that. No more repetitive constructor assignments just declare your parameters once, and you’re set.

Here’s a quick example:

public class User(string name, string email)
{
    public string Name { get; } = name;
    public string Email { get; } = email;
}

Besides that, lambdas and pattern matching keep improving every release, and string interpolation is now both faster and safer. All these little changes add up and make daily coding genuinely nicer.

4. ASP.NET Core: Strongly Typed Minimal APIs with Source Generators

Minimal APIs were already a breath of fresh air for small services, but .NET 10 takes it up a notch. The new source generators make reflection mostly a thing of the past, and you get full type safety for your endpoints. It’s the sort of feature that makes refactoring APIs less nerve-wracking and really speeds up the "write it, test it, ship it" cycle.

Here’s how clear your endpoint code can look now:

app.MapPost("/users", (UserRequest request) => Results.Ok(request))
   .WithName("CreateUser");

Less magic, more compile-time safety, and no more second-guessing your routes.

5. Smarter Entity Framework Core: Bulk Operations & Performance

If you work with large datasets or ever had to write a manual loop just to update rows, this one’s for you. The new bulk operations like BulkUpdate and BulkDelete in EF Core have saved me from so much tedium and boosted performance in the process.

Here’s an example:

context.Users.Where(u => u.IsActive)
    .ExecuteUpdate(u => u.SetProperty(x => x.LastLogin, DateTime.UtcNow));

You can now update or delete hundreds or thousands of rows with a single, efficient query. I wish this existed a few projects ago!

Conclusion

I’ll be honest: I don’t adopt every new .NET feature right away, but .NET 9 and 10 have a lot of compelling reasons to upgrade. Native AOT and observability alone are enough to simplify deployment and maintenance, and the C# and EF Core upgrades make writing and maintaining code more enjoyable. If you’re looking for ways to build faster, cleaner, and more reliable apps, these releases are well worth your attention.

What new .NET feature are you most excited to try? Drop your thoughts below always happy to geek out about new tech!

Happy coding! 🚀

C# 12: Embracing the Quirks and Magic of Modern Programming

JKC — Sun, 30 Jul 2023 14:56:41 +0000

Introduction:

Welcome to the exciting world of C# 12, where modern programming meets a touch of magic and humor! In this blog, we will explore the latest features introduced in C# 12, from primary constructors to code sorcery. So fasten your seatbelts, and let's dive into the quirky wonders of C#!

Constructors: A Constructor Revolution

Constructors are the architects of object creation, and C# 12 brings a revolution with "Primary Constructors." Now, they are not just for record types; you can use them in any class or struct! Primary constructor parameters are in scope for the entire class, reducing boilerplate code. And remember to call the primary constructor from other constructors using "this()". Say goodbye to the mundane and welcome cleaner, more concise code!

// Primary constructor example
public class Person
{
    public string Name { get; }
    public int Age { get; }

    public Person(string name, int age)
    {
        Name = name;
        Age = age;
    }
}

Default Lambda Parameters: Embracing Laziness!

Lambdas are powerful, and C# 12 takes them a step further with "Default Lambda Parameters." Now, you can give your lambdas default values, just like regular methods. This lazy addition to lambdas simplifies your code without sacrificing functionality. Embrace the power of defaults and let your lambdas take it easy!

// Default Lambda Parameters
Func<int, int, int> addNumbers = (x, y = 10) => x + y;

// Usage
int result1 = addNumbers(5);      // result1 = 5 + 10 = 15
int result2 = addNumbers(5, 7);   // result2 = 5 + 7 = 12

Alias Any Type: The Language of Your Code

Aliases just got a significant upgrade! With "Alias Any Type," you can create semantic aliases for any type, not just named ones. Tuple types, array types, pointers - anything you want! Give your code a unique language of its own and let your creativity flow.

// Alias Any Type
using MyArray = int[];  // Alias for int array

public class Example
{
    public void UseAlias()
    {
        MyArray numbers = new MyArray { 1, 2, 3, 4, 5 };
        foreach (var num in numbers)
        {
            Console.WriteLine(num);
        }
    }
}

Inline Arrays: Compact and Speedy!

Inline arrays are here to supercharge your apps! They allow developers to create fixed-size arrays in struct types without the usual overhead. As a developer, you might not create them directly, but you'll enjoy their benefits through System.Span or System.ReadOnlySpan objects from runtime APIs. Get ready for compact and speedy performance!

[System.Runtime.CompilerServices.InlineArray(10)]
public struct Buffer
{
    private int _element0;
}

// Usage
var buffer = new Buffer();
for (int i = 0; i < 10; i++)
{
    buffer[i] = i;
}

foreach (var i in buffer)
{
    Console.WriteLine(i);
}

Interceptors: Unleashing Code Sorcery (Experimental)

Caution: Interceptors are experimental and not for production use.

Interceptors provide a glimpse into the world of code sorcery! This experimental feature allows you to declaratively substitute calls to interceptable methods with your custom logic at compile time. Think of it as a source generator's magic wand, modifying existing code rather than adding new code. But beware, with great power comes great responsibility!

[Interceptable]
public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

// Interceptor method
[Interceptor(nameof(CustomAdd))]
public int InterceptedAdd(int a, int b)
{
    Console.WriteLine("Interceptor activated!");
    return CustomAdd(a, b);
}

// Usage
var calculator = new Calculator();
int result = calculator.Add(5, 7);   // The Interceptor will be invoked if enabled.

Conclusion:

Congratulations, adventurous programmers! You've now journeyed through the quirky world of C# 12, from primary constructors to code sorcery. Embrace these new features and let them infuse magic into your code. But remember, with great magic comes great responsibility! Enjoy exploring these innovative additions to C# and continue pushing the boundaries of your coding adventures. Happy coding, and may the quirks be with you!

Exploring the New Visual Studio Feature: .http Files

JKC — Mon, 05 Jun 2023 15:16:04 +0000

Introduction:

Visual Studio, the popular integrated development environment (IDE) by Microsoft, continually evolves to enhance developers' productivity and streamline their workflows. In the latest release, a new feature has been introduced: .http files. These files provide a convenient way to interact with HTTP APIs directly within Visual Studio. In this blog post, we will delve into the details of .http files, explore code examples in C#, discuss the system dynamic variables available, and highlight their similarity to the Visual Studio Code extension, "REST Client."

Understanding .http Files:

.HTTP files in Visual Studio act as a lightweight HTTP client, allowing developers to write and execute HTTP requests directly in the IDE. These files are inspired by the Visual Studio Code extension called "REST Client" and provide a similar experience within Visual Studio itself. They are designed to simplify the process of testing and debugging HTTP APIs.

Creating an .http File:

To create an .http file in Visual Studio, follow these steps:

Right-click on your project or desired location in the Solution Explorer.
Choose "Add" and then "New Item."
Select "Text File" from the available templates and name it with the .http extension.

Writing HTTP Requests in C#:

Let's explore some code examples to demonstrate how to use .http files effectively in Visual Studio using C#. Assume we have an API endpoint at "https://api.example.com/users" that returns a list of users in JSON format.

Sending a GET Request:

GET https://api.example.com/users

HTTP/1.1
Host: api.example.com

Sending a POST Request:

POST https://api.example.com/users

Content-Type: application/json

{
  "name": "John Doe",
  "email": "john.doe@example.com"
}

System Dynamic Variables in .http Files:

Visual Studio's .http files provide a set of system dynamic variables that you can utilize to enhance your HTTP requests. These variables simplify the process of including dynamic values in your requests, such as environment-specific URLs or authentication tokens.

Here are the system dynamic variables available in .http files:

{{guid}}: Generates a new GUID for each request.
{{randomInt}}: Generates a random integer for each request.
{{timestamp}}: Represents the current timestamp.
{{date}}: Represents the current date.
{{time}}: Represents the current time.
{{utcDate}}: Represents the current UTC date.
{{utcTime}}: Represents the current UTC time.
{{month}}: Represents the current month.
{{year}}: Represents the current year.
{{host}}: Represents the current host URL.

Example using system dynamic variables:

POST https://api.example.com/users

Content-Type: application/json

{
  "id": "{{guid}}",
  "name": "John Doe",
  "email": "john.doe@example.com"
}

###

GET https://api.example.com/logs?timestamp={{timestamp}}

###

Conclusion:

With the introduction of .http files in Visual Studio, developers now have a convenient way to interact with HTTP APIs directly within their IDE. These files provide a familiar and intuitive syntax, making it easier to test and debug APIs without leaving the development environment. By utilizing system dynamic variables, developers can enhance their HTTP requests and streamline their workflows further. .http files in Visual Studio resemble the functionality of the "REST Client" extension in Visual Studio Code, providing a seamless experience across platforms.

Start leveraging this powerful feature today and experience the productivity boost it offers!

Happy coding with Visual Studio and .http files!

(Note: The code examples provided in this blog are for demonstration purposes only. Actual implementation may vary depending on the specific HTTP API and requirements.)

Pattern Matching Enhancements in C# 9: Exploring New Patterns

JKC — Wed, 10 May 2023 15:07:45 +0000

As a C# developer, you're probably familiar with pattern matching. This feature allows you to test whether an expression matches a certain pattern and execute different code based on the result. In C# 9, Microsoft introduced several enhancements to pattern matching, including new patterns that make your code more concise and readable. In this blog post, I'll explore some of these new patterns and show you how to use them in your code.

Logical Patterns

The logical patterns and, or, and not allow you to combine patterns into more complex expressions. For example, suppose you have a method that takes an object and performs different actions depending on its type and value. Using logical patterns, you can define a single switch statement that handles all cases:

void ProcessObject(object obj)
{
    switch (obj)
    {
        case string s and ({ Length: > 0 } or null):
            Console.WriteLine($"The string is '{s ?? "null"}'");
            break;
        case int i and >= 0:
            Console.WriteLine($"The integer is {i}");
            break;
        case bool b:
            Console.WriteLine($"The boolean is {b}");
            break;
        default:
            Console.WriteLine("Unknown object");
            break;
    }
}

In this example, the first case uses the logical pattern and to test whether the object is a non-empty string or null. It also uses the property pattern to check that the string has a length greater than zero. The second case uses the relational pattern >= to test whether the object is a non-negative integer. The third case uses a simple type pattern to test whether the object is a boolean. Finally, the default case handles all other cases.

Relational Patterns

Relational patterns allow you to test whether an expression matches a certain relationship with a value. C# 9 introduces several new relational patterns, including >, <, >=, and <=. For example, suppose you have a method that takes a list of integers and prints the first number that is greater than 10:

void PrintFirstGreaterThan10(List<int> list)
{
    foreach (var i in list)
    {
        if (i is > 10)
        {
            Console.WriteLine($"The first number greater than 10 is {i}");
            return;
        }
    }

    Console.WriteLine("There are no numbers greater than 10");
}

In this example, the is operator is used with the relational pattern >. This pattern tests whether the value of i is greater than 10. If so, it prints the number and returns from the method. Otherwise, it continues to the next number. If there are no numbers greater than 10, the method prints a message indicating that.

Type Patterns

Type patterns allow you to test whether an expression is of a certain type and optionally bind it to a new variable. In C# 9, you can use the or pattern to test whether an expression is of one type or another. For example, suppose you have a method that takes an object and prints its type:

void PrintType(object obj)
{
    switch (obj)
    {
        case string s or int i:
            Console.WriteLine($"The type of the object is {obj.GetType().Name}");
            break;
        default:
            Console.WriteLine("Unknown type");
            break;
    }
}

In this example, the switch statement uses the or pattern to check whether the object is either a string or an int. If the object is a string or an int, the method prints its type. Otherwise, it prints "Unknown type".

Conclusion

Pattern matching is a powerful feature in C# that allows developers to write concise and readable code. C# 9 introduces new patterns, such as logical patterns, relational patterns, and type patterns, which enable even more flexibility in handling different cases in code. By using these patterns, you can simplify your code and make it more expressive.

Introducing C# 9.0's Record Datatype: Safe, Efficient, and Easy to Use

JKC — Fri, 14 Apr 2023 10:55:27 +0000

C# 9.0 introduces a new datatype called record, which is an immutable type that provides value-based equality. Records are ideal for representing data that is primarily for storage and retrieval. In this blog post, we'll explore the features and benefits of records, how to create them, and how they can be used in C# code through code examples.

Features and Benefits

The record datatype in C# has several features and benefits, including:

Immutability: Records are immutable, which means their values cannot be changed once they're created. This feature ensures records are safer to use because they can't be modified after they're created.

Value-Based Equality: Records provide value-based equality, which means that two records are equal if their values are equal. This feature makes it easy to compare records and determine if they're the same.

Built-In Deconstruction: Records have built-in deconstruction, which allows you to easily extract their values and assign them to variables. This feature makes it easy to work with records and use their values in your code.

Concise Syntax: The syntax for creating records is concise, making it easy to create and use them in your code. This feature saves time when writing code and makes it easier to work with records.

Creating Records

To create a record in C#, you use the record keyword followed by the name of the record and its properties. Here's an example:

public record Person(string FirstName, string LastName, int Age);

In this example, the Person record has three properties: FirstName, LastName, and Age. These properties are used to store the person's first name, last name, and age.

Using Records

Records can be used in many ways in C# code. Here are some examples:

Creating a list of records:

List<Person> people = new List<Person>()
{
    new Person("John", "Doe", 30),
    new Person("Jane", "Doe", 25)
};

In this example, we've created a list of Person records and added two records to the list. We've also specified the values for each property when we created the records.

Using records as function return types:

public record Person(string FirstName, string LastName, int Age);

public Person GetPerson()
{
    return new Person("John", "Doe", 30);
}

var person = GetPerson();

In this example, we've created a function that returns a Person record. We've then assigned the returned record to a variable, which can be used later in the code.

Deconstructing records:

var person = new Person("John", "Doe", 30);
var (firstName, lastName, age) = person;

In this example, we've created a Person record and then deconstructed it to extract its values. The values are then assigned to variables, which can be used later in the code.

Conclusion

In conclusion, the new record datatype in C# 9.0 is a powerful tool that can be used to store and retrieve data in a safe and efficient way. Its features, such as immutability, value-based equality, built-in deconstruction, and concise syntax, make it easy to use and save time when writing code. Records can help streamline code and improve its readability and maintainability. Whether you're working on a small project or a large-scale application, records can be a useful addition to your C# toolbox.

Simplify Your Debugging Process with Visual Studio Group Breakpoints

JKC — Thu, 06 Apr 2023 14:10:50 +0000

Visual Studio is a powerful integrated development environment that provides many useful tools for developers. One such tool is the Group Breakpoints feature, which allows you to set breakpoints for multiple lines of code at once. This can be especially useful when debugging complex applications that have many different code paths, or when debugging code that is spread out over multiple files.

To use Group Breakpoints in Visual Studio, follow these steps:

Open the code file that you want to debug.
Select the lines of code that you want to group together.
Right-click on the selected lines of code and choose "Breakpoint" from the context menu.
In the Breakpoint menu, select "Insert Group Breakpoint."

Once you have set a Group Breakpoint, Visual Studio will display a blue rectangle in the left margin of the code editor to indicate the location of the breakpoint. When the code reaches this breakpoint, the debugger will stop and allow you to inspect the state of the application.

Group Breakpoints can be especially useful when debugging code that is spread out over multiple files. For example, if you have a complex function that is defined in multiple files, you can select all the lines of code that make up the function, right-click, and choose "Insert Group Breakpoint." This will create a single breakpoint that covers all the lines of code for the function, making it easier to debug the code and find any errors.

Group Breakpoints can also be useful when debugging code that has multiple methods. Rather than setting individual breakpoints for each method, you can select all the lines of code for each method, right-click, and choose "Insert Group Breakpoint." This will create a single breakpoint that covers all the lines of code for each method, making it easier to debug multiple methods at once.

To remove a Group Breakpoint, simply right-click on the blue rectangle in the left margin and choose "Delete Group Breakpoint" from the context menu.

In conclusion, Group Breakpoints are a powerful tool for debugging complex applications in Visual Studio. They can help you save time and effort by allowing you to set breakpoints for multiple lines of code at once, making it easier to debug your code and find any errors. By following the steps outlined above, you can easily use Group Breakpoints to debug your own applications and streamline your development workflow.