DEV Community: VLAD

What async/await Actually Does in C# (and Where One .Result Costs You 3 Seconds)

VLAD — Sat, 31 Oct 2026 22:23:49 +0000

Microsoft has a tutorial on debugging thread pool starvation. Its sample app has an ASP.NET Core endpoint with a fake database call of about half a second. The tutorial hits it with 125 concurrent connections. With .Result in the code, the average response takes 3.48 seconds. With await instead, it takes 532 ms.

The work and the database are the same. So where do three seconds go? To answer that, you need to know what await actually does.

The myth: async means another thread

It doesn't. async doesn't start anything. await means one thing: if this isn't done yet, give the thread back.

The thread goes off and serves another request. When the answer comes, a thread picks up where your method left off. It may not be the same thread.

Who waits for the database?

During that half second, no thread is waiting. The request is out on the network, and the operating system tracks it. When the answer arrives, the OS tells .NET, and a thread pool thread runs the rest of your method for a moment. Then that thread is free again.

Stephen Cleary's classic post There Is No Thread walks through this down to the device driver. The practical consequence is in Microsoft's ASP.NET Core Best Practices: asynchronous APIs let a small pool of threads handle thousands of concurrent requests, because none of them sit waiting on blocking calls.

So async doesn't make one request faster. It lets one server handle more of them.

The compiler rewrites your method

A method can't stop in the middle and come back later. So the C# compiler rewrites it. Take this method:

public async Task<Order> GetOrderAsync(int id)
{
    var json = await http.GetStringAsync($"/orders/{id}");
    var order = Parse(json);
    await db.SaveAsync(order);
    return order;
}

It becomes a hidden state machine, a type that implements IAsyncStateMachine:

Your local variables become fields, so they survive the pause.
Every await gets a number, a bookmark.
One method, MoveNext, holds your code. It starts by reading the state and jumping to the matching bookmark.

Simplified, it looks like this:

struct GetOrderAsyncStateMachine : IAsyncStateMachine   // simplified
{
    public int state;          // -1 = not started · 0, 1 = which await
    private string json;       // your local, now a field

    public void MoveNext()
    {
        switch (state)
        {
            case 0: goto AfterAwait0;
            case 1: goto AfterAwait1;
        }
        // ...your code, cut at every await
    }
}

In release builds it's a struct, and in debug builds it's a class. Stephen Toub's How Async/Await Really Works in C# is the long version, with the real generated code.

What one `await` turns into

Here's a single await, simplified:

var awaiter = http.GetStringAsync(url).GetAwaiter();
if (!awaiter.IsCompleted)
{
    state = 0;                                              // the bookmark
    builder.AwaitUnsafeOnCompleted(ref awaiter, ref this);  // "call me back"
    return;                                                 // thread is free
}
AfterAwait0:
json = awaiter.GetResult();

Ask the task: are you done?
If not, save the bookmark, tell the task what to call when it finishes, and return. That return is the moment your thread goes free.
When the task finishes, MoveNext runs again, jumps to the bookmark, and reads the result.

Now look at the if again. If the task is already done, there's no pause at all: no bookmark, no thread switch. The code just keeps going. As the ConfigureAwait FAQ puts it, awaits on already-completed awaitables keep running past the await synchronously. So an async method can run from start to finish on the calling thread without ever giving it up. Async doesn't mean it waited.

Where does the rest of the method run?

When await does pause, it captures a context (SynchronizationContext.Current, or a non-default TaskScheduler) and resumes there:

WPF / WinForms have a UI context. The rest of your method goes back to the UI thread, so it can touch the screen.
ASP.NET Core has no SynchronizationContext. The rest runs on any free thread pool thread.

The `.Result` deadlock

This is where .Result gets dangerous in a desktop app:

A button click calls an async method, then .Result. The UI thread stops and waits.
Inside, the await finishes. The rest of the method needs to run on the UI thread.
But the UI thread is busy, waiting for that same method.

Each one waits for the other, forever. Run the same code in a console app and it works, which is why it passes your tests. Stephen Cleary's Don't Block on Async Code has the step-by-step version.

ASP.NET Core: no deadlock, still slow

ASP.NET Core has no context, so this deadlock doesn't happen there. The problem is still there, though.

Every .Result holds a thread pool thread that does nothing for the whole database call. With 125 requests at once, the pool runs out of free threads. New work waits in a queue, and the pool adds threads, but not fast enough. That's thread pool starvation, and that's where the three seconds in the demo went. Microsoft's tutorial calls sync-over-async the most common cause of it.

The fix

Async all the way. Await from the controller down to the database call, with no .Result or .Wait() in between. The best practices page says it directly: don't block asynchronous execution with Task.Wait or Task.Result.
ConfigureAwait(false) in shared library code. It tells await not to come back to the captured context.

  var json = await http.GetStringAsync(url).ConfigureAwait(false);

In app code, leave it out. That's Toub's advice in the FAQ. It's a safety net in libraries, not the fix for a deadlock.

Two more traps

async void. An async Task method puts its exception on the task, so you can await it and catch it. async void has no task, so the exception has nowhere to land, and the caller's try/catch never sees it. In ASP.NET Core, Microsoft calls async void "ALWAYS a bad practice", and its example crashes the process. Use it only for event handlers.

Task.Run isn't async. It moves the work to another thread pool thread, and that thread still does the work or blocks. On a server you're already on a pool thread, so Microsoft's guidance is to not call Task.Run and immediately await it. Async helps when you wait, not when you compute.

The JavaScript difference

If you also write JavaScript:

JavaScript runs your code on one thread, and a Promise has no .Result. You can't block on it, so this deadlock can't happen there. await never blocks the main thread.
In JavaScript, await always pauses, even on a promise that's already fulfilled. The rest of the function runs in a later microtask.
In C#, await on a finished task doesn't pause at all.

What to look for in your code

.Result and .Wait() on a task → replace with await.
async void outside event handlers → return Task.
await Task.Run(...) right away in a controller → just call the method.
Shared libraries → ConfigureAwait(false).

await doesn't start a thread. It gives one back, and the compiler keeps a bookmark so your method can come back later. The danger isn't await. It's the code that blocks while it waits.

Have you ever hit the .Result deadlock? How long did it take you to find it?

I make Vlad's Stack: short explainers on how the tools you use every day actually work, for .NET and full-stack developers. More at https://www.youtube.com/@VladsStack .

LLM Tokens, Measured in C#: Why AI Can't Count the R's in Strawberry

VLAD — Sat, 31 Oct 2026 22:16:46 +0000

In August 2024, TechCrunch asked a simple question: how many R's are in "strawberry"? According to GPT-4o and Claude at the time, two. The answer is three.

The model isn't bad at counting. It never saw the letters. It saw tokens, and every token is just a number.

Every token count in this article was measured by me on October 30, 2026, with Microsoft's own .NET library, Microsoft.ML.Tokenizers 2.0.1, using the tokenizer for gpt-5 (the same o200k_base encoding GPT-4o uses). The program is at the end, so you can check them.

What the model actually gets

Before your prompt reaches the model, a tokenizer cuts it into pieces, called tokens, and turns each piece into an ID from a fixed list.

How many r's are in strawberry? becomes 8 tokens:

Token	`How`	`many`	`r`	`'s`	`are`	`in`	`strawberry`	`?`
ID	5299	1991	428	885	553	306	101830	30

Look at strawberry, with the space in front. It's one token: number 101830. The R's are inside that number, and the model can't open it.

Spell the word out with spaces, s t r a w b e r r y, and it becomes 10 tokens. Three of them are r (ID 428). Now there's something to count.

Where tokens come from: byte pair encoding

Before the model is trained, the tokenizer learns from a big pile of text:

Start with single bytes.
Find the pair of neighbors that shows up most often, and glue it into a new token.
Repeat, until the list reaches a fixed size. For GPT-4o's encoding, o200k, that's about 200,000 tokens.

This is byte pair encoding. It started as a compression algorithm, and was adapted for words in Sennrich, Haddow and Birch (2016). OpenAI's tiktoken README lists what you get from it: it's lossless, it works on any text, and on average one token is about 4 bytes.

The result: common text becomes one token, rare text becomes pieces.

tokenization → token · ization
Strawberry at the start of a line → Str · aw · berry (3 tokens)
strawberry in the middle of a sentence → 1 token

Same word, different splits, depending on a capital letter and a space.

The same sentence costs more in other languages

I'm Romanian, so I measured this one first:

English: "Your order has shipped. You can track it in your account, and it should arrive within three business days." → 22 tokens
Romanian: "Comanda ta a fost expediată. O poți urmări în contul tău și ar trebui să ajungă în trei zile lucrătoare." → 34 tokens

That's about 55% more for the same meaning. Common English words got their own tokens. Romanian words get cut up: urm·ări, t·ă·u, lucr·ăto·are. The same answer costs more and fills the context window faster.

Numbers get cut too

2026 → 202 · 6
1234567 → 123 · 456 · 7 (groups of three, from the left)

A 2024 paper, Tokenization counts (Singh and Strouse), notes that GPT-3.5 and GPT-4 have separate tokens for 1-, 2- and 3-digit numbers, and that forcing the digits to group from the right, just by adding commas, made the models much better at addition.

Your code, and the expensive part

This C# method is 234 characters and 59 tokens:

public async Task<List<Order>> GetRecentOrdersAsync(int customerId)
{
    return await _db.Orders
        .Where(o => o.CustomerId == customerId)
        .OrderByDescending(o => o.CreatedAt)
        .Take(10)
        .ToListAsync();
}

Indentation is cheap: a run of spaces is usually one token. Common identifiers like Where and Async are cheap too.

Now a GUID: 3f2b8c1e-9d4a-4e7b-a1c2-5d6e7f809a1b. 36 characters, 33 tokens. Almost one token per character, because random hex has no common pieces to glue together. A log full of GUIDs, hashes or base64 eats your context window much faster than the same length of prose.

Why this matters

Price is per token, input and output priced separately (Claude pricing).
The context window is measured in tokens.
Rate limits are in tokens per minute (Claude rate limits).

Characters and words don't matter. Tokens do.

Every model has its own tokenizer

ToListAsync is one token for GPT-4's tokenizer (cl100k_base) and three for GPT-4o's (To · List · Async).

It changes inside one family too. Anthropic's token counting docs say Claude models from Opus 4.7 on use a newer tokenizer, and the same text comes out about 30% higher than on earlier models. A count from one model is a guess for another. Count with the model you actually call.

Counting tokens in .NET

dotnet add package Microsoft.ML.Tokenizers
dotnet add package Microsoft.ML.Tokenizers.Data.O200kBase

using Microsoft.ML.Tokenizers;

// Create once, reuse it.
Tokenizer tok = TiktokenTokenizer.CreateForModel("gpt-5");

int count = tok.CountTokens(prompt);

It can also cut text to a budget, without guessing with character counts:

int end = tok.GetIndexByTokenCount(
    text, 4000, out string? normalized, out _);
string chunk = (normalized ?? text)[..end];

The library covers Tiktoken (the GPT encodings), Llama, BPE and a few others. For Claude, ask the API: POST /v1/messages/count_tokens counts with the tokenizer of the model you pass. It's free (with rate limits), and the docs call it an estimate that can differ from the real usage by a small amount.

Back to strawberry

Newer models often get the strawberry question right. And you can help any model: ask it to spell the word letter by letter, and each letter becomes its own token. But the tokens didn't go away. Under the hood, the model still reads IDs, not letters.

The measurement program

// dotnet add package Microsoft.ML.Tokenizers
// dotnet add package Microsoft.ML.Tokenizers.Data.O200kBase
using Microsoft.ML.Tokenizers;

var tok = TiktokenTokenizer.CreateForModel("gpt-5");
foreach (var t in tok.EncodeToTokens(" strawberry", out _))
    Console.WriteLine($"[{t.Value}] #{t.Id}");   // [ strawberry] #101830

Console.WriteLine(tok.CountTokens("3f2b8c1e-9d4a-4e7b-a1c2-5d6e7f809a1b")); // 33

What's the most expensive thing you paste into a prompt? Logs, JSON, a whole file? Tell me in the comments.

I make Vlad's Stack — short explainers about how the tools you use every day actually work, for people who write code (.NET-flavored). The video version of this article: https://www.youtube.com/@VladsStack

Why TypeScript 7 Is Written in Go, Not C#: 43 Years of Anders Hejlsberg

VLAD — Sat, 31 Oct 2026 17:21:20 +0000

On July 8, 2026, TypeScript 7 shipped: the same compiler, ported to a new language, and about ten times faster. On the VS Code codebase, a full build went from 125.7 seconds to 10.6 seconds.

The port had been announced in March 2025 by Anders Hejlsberg, the man who designed C#. And the new language wasn't C#. It was Go.

To see why that makes sense, it helps to go back 43 years. Across four languages, one idea keeps coming back: the time between typing your code and seeing what it does.

A compiler from Denmark

In the early 1980s, Hejlsberg wrote a Pascal compiler for small personal computers in Denmark. It was sold as Compass Pascal, and later as Poly Pascal. A young California company, Borland, licensed it, and Hejlsberg stayed in Denmark: according to Dr. Dobb's, Borland sent him 9600-baud modems so he could send each new build to California.

Turbo Pascal, 1983

On November 20, 1983, it shipped as Turbo Pascal. The numbers, again from Dr. Dobb's:

$49.95, when its nearest competitor cost nearly $500
one floppy disk, ten files
TURBO.COM, the main program, was 33,280 bytes

The editor and the compiler lived in one program. You typed, compiled and ran without leaving it. Hejlsberg later wrote that back in the old Turbo Pascal days, it was possible for one person to write and maintain an entire product.

Delphi, 1995

Windows brought windows, buttons and menus, and building them by hand meant pages of code. On February 14, 1995, Borland launched Delphi in San Francisco, with Hejlsberg as chief architect. You drew a window, dropped a button on it and wrote what should happen on click. Underneath, it was still Pascal, grown out of Turbo Pascal.

C

In 1996 he joined Microsoft. In June 2000, Microsoft announced C#, with Hejlsberg as lead designer (the ECMA-334 standard names him first among its principal inventors). The goal, as described at the time: the power of C++ with the ease of Visual Basic.

That Delphi button followed him. In C#, a click calls your method through a delegate, and every event you write works that way. (How delegates ended up in C# is its own story, involving Sun and a court order: Why C# Exists.)

He stayed with C# as it grew: generics in 2005, LINQ in 2007, async/await in 2012.

TypeScript, 2012

By 2012, people were building JavaScript applications of a size the language was never planned for. Some teams inside Microsoft used tools like Script# to write C# and compile it to JavaScript. TypeScript went the other way: don't hide JavaScript, put types on top of it.

Microsoft introduced TypeScript on October 1, 2012. Every JavaScript program was already a TypeScript program, and the types are erased when you compile. So what are they for? For the tools: errors as you type, autocomplete, safe renames. It's the Turbo Pascal idea again. The fastest feedback is the one you get before you run the code.

The slow compiler

TypeScript took over. By 2025, VS Code alone was about 1.5 million lines of it. But the compiler was itself written in TypeScript, running as JavaScript. On VS Code, tsc took 77.8 seconds, and just opening the project in the editor took about 9.6 seconds.

In March 2025, Hejlsberg wrote the announcement: a native port of the compiler. Not a rewrite. A port: the same logic, moved over piece by piece, so it behaves the same.

One thing worth stating plainly: your TypeScript code didn't change. Only the program that checks it did.

Why Go, not C

Plenty of C# developers asked. The team answered in public, in a “Why Go?” FAQ:

It's a port, so the code shape matters most. "Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase", which is mostly plain functions and data structures rather than classes.
Memory control with a garbage collector. Go lets them control how data is laid out in memory, without managing memory by hand.
Batch builds can skip GC. "Batch compilations can effectively forego garbage collection entirely, since the process terminates at the end."

In an interview with Michigan TypeScript in March 2025, as reported by devclass, Hejlsberg said they did consider C#, but that C# is bytecode-first and its native (AOT) compilation wasn't available on every platform they needed.

So it wasn't a verdict on C#. It was the tool that fit this one job.

TypeScript 7

TypeScript 7 shipped on July 8, 2026, with full builds typically 8 to 12 times faster. On VS Code, a full build went from 125.7 s to 10.6 s, and the time until the first error appears in the editor dropped from about 17.5 seconds to under 1.3.

One idea, four languages

Turbo Pascal, Delphi, C#, TypeScript. Different companies, different platforms. Each time, the tool around the language mattered as much as the language. And when his own compiler got slow, his team didn't reach for his own language. They reached for the one that fit the job.

Would you have ported it to C#? Tell me in the comments.

I make Vlad's Stack — short explainers and stories about how the tools you use every day actually work, for people who write code (.NET-flavored). The video version of this story: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

Isolation Levels: How the Last Item in Stock Gets Sold Twice

VLAD — Thu, 29 Oct 2026 21:31:28 +0000

Two customers buy the last item in stock at the same second. Both orders go through. Every line of your code ran inside a transaction, and SQL Server did exactly what its default setting promises.

That setting is the isolation level. There are four of them. This post walks through each one, the anomaly it stops, and the .NET class that quietly picks the strictest one for you.

A transaction isn't a freeze

A transaction promises all or nothing: your changes land together, or not at all. What it doesn't promise is that the world stops while you work. Other transactions keep reading and writing while yours runs.

How much of their work you can see is a dial, and that dial is the isolation level. It has four steps:

Read uncommitted
Read committed
Repeatable read
Serializable

Each step up protects you from one more anomaly. Each step up also makes somebody wait longer.

The three anomalies are:

Dirty read: you read data another transaction hasn't committed yet.
Non-repeatable read: you read the same row twice and get two values.
Phantom read: you run the same query twice and get a different set of rows.

Read uncommitted: a price that never existed

Transaction 1 sets a price to zero and hasn't committed. Transaction 2 reads the price and sees zero. Then transaction 1 rolls back. Transaction 2 just used a price that never existed. That's a dirty read.

You've probably seen this level in production code without its name on it:

SELECT SUM(Total) FROM Orders WITH (NOLOCK);

People add NOLOCK so a report stops waiting on writers. But the SQL Server docs are direct about it: read uncommitted has the same effect as NOLOCK on every table in every SELECT. Dirty reads are included, and rows can appear or disappear in the data set while you read. NOLOCK isn't a speed setting. It's agreeing to read data that might never exist.

Read committed: same SELECT, two answers

One step up is read committed, the default on both SQL Server and PostgreSQL. You only see committed data, so dirty reads are gone.

But data can still change between two statements of your transaction:

T1	T2
`SELECT balance` → 100
	`UPDATE` → 50, `COMMIT`
`SELECT balance` → 50

Same query, same transaction, two answers. That's a non-repeatable read.

The lost update: where the two customers come from

Here's the stock bug in ordinary EF Core code:

var p = await db.Products.SingleAsync(x => x.Id == id);   // Stock = 1
if (p.Stock > 0)
    p.Stock -= 1;
await db.SaveChangesAsync();                              // SET Stock = 0

Run it twice at the same time under read committed. Both requests read Stock = 1. Both pass the check. Both send UPDATE ... SET Stock = 0. Two orders, one item, and nobody gets an error. That's a lost update.

You can fix it without touching the isolation level.

Option 1: one atomic statement. Put the check in the WHERE and let the database do the subtraction with ExecuteUpdateAsync:

var changed = await db.Products
    .Where(x => x.Id == id && x.Stock > 0)
    .ExecuteUpdateAsync(s => s.SetProperty(x => x.Stock, x => x.Stock - 1));

if (changed == 0)
{
    // sold out
}

ExecuteUpdateAsync returns the number of rows it changed. Zero means somebody else got the last one.

Option 2: a concurrency token. Add a rowversion column with [Timestamp]. EF Core adds the original version to the WHERE of the update, so the second save matches zero rows and throws DbUpdateConcurrencyException.

Either way, the second buyer sees "sold out", not a free item.

Repeatable read: rows you read stay locked

At repeatable read, SQL Server places shared locks on every row you read and holds them until the transaction ends. Nobody can change those rows, so your second SELECT gets the same answer.

Run the stock code at this level and the lost update is gone, but something else shows up. Both buyers read the stock and keep their shared locks. Both then try to update, and each one waits for the other. SQL Server detects the deadlock, picks one transaction as the victim, rolls it back, and raises error 1205: "chosen as the deadlock victim. Rerun the transaction."

The bug is fixed. The price is that you now need a retry.

Phantoms: 10 seats, 11 people

Repeatable read has a hole. It locks rows that exist. It can't lock a row that isn't there yet.

A workshop has 10 seats. Request A counts the sign-ups: 9. There's room, so it inserts one. Request B runs the same count at the same time, also sees 9, and inserts too. Eleven people, ten seats. The new row that appeared under request B's feet is a phantom.

Serializable: lock the whole range

Serializable places range locks on the key range your query read. "Sign-ups for workshop 7" becomes a range nobody can insert into until you commit. The result behaves as if the transactions ran one at a time.

The cost: more waiting, more deadlocks, more retries. It's the safest level, and the slowest.

The whole dial

This is the SQL standard's version (PostgreSQL's docs have the clearest table):

Level	Dirty read	Non-repeatable read	Phantom
Read uncommitted	possible	possible	possible
Read committed	no	possible	possible
Repeatable read	no	no	possible
Serializable	no	no	no

Your database might not follow it exactly.

Same name, different behavior

SQL Server. The default read committed uses locks: a reader waits for a writer to finish. Turn on the READ_COMMITTED_SNAPSHOT database option and readers get the last committed version of the row instead, with no waiting. Same level name, different behavior. On Azure SQL Database that option is on by default, so the same code can block on your laptop and not in the cloud. You can check yours:

SELECT name, is_read_committed_snapshot_on FROM sys.databases;

PostgreSQL. Read uncommitted behaves like read committed, so you can't get a dirty read at all. Its repeatable read doesn't allow phantoms either. But the workshop bug still gets through, because both transactions count from their own snapshot and both insert: that's a serialization anomaly, and only serializable stops it, by failing one transaction with SQLSTATE 40001 that you retry.

MySQL (InnoDB). The default is repeatable read, not read committed.

What EF Core and .NET pick for you

EF Core picks nothing. It uses your database's default, and SaveChanges applies its changes in a transaction at that level. To choose a level, pass it when you begin the transaction:

await using var tx = await db.Database
    .BeginTransactionAsync(IsolationLevel.Serializable);

TransactionScope picks the strictest one. Write new TransactionScope() with no options and, by default, the transaction runs at Serializable. That's range locks, more waiting and more deadlocks on every query inside it, and you never asked for any of it. Pass TransactionOptions and pick the level yourself:

using var scope = new TransactionScope(TransactionScopeOption.Required,
    new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted },
    TransactionScopeAsyncFlowOption.Enabled);

(TransactionScopeAsyncFlowOption.Enabled is what lets the ambient transaction flow across await, per the EF Core docs.)

A checklist for your own app

Know your default. One query on sys.databases tells you whether read committed snapshot is on.
Treat NOLOCK as a bug, not a speed fix.
Read, then write? Use one UPDATE with the check in the WHERE, or a concurrency token.
Find every new TransactionScope() and give it a level.
If you move up the dial, write the retry (error 1205 on SQL Server, SQLSTATE 40001 on PostgreSQL).

A transaction doesn't stop others from touching your data. The isolation level decides how much they can, so pick it on purpose, before your users find the default for you.

Which isolation level does your app run at right now? Do you know it without checking? Tell me in the comments.

I make Vlad's Stack — short explainers on how the tools you use every day actually work, for people who write code (.NET-flavored). The video version of this post is on the channel: https://www.youtube.com/@VladsStack

EF Core Isn't Slow. These 5 Query Patterns Are.

VLAD — Thu, 29 Oct 2026 21:25:12 +0000

Four lines of C# can send 101 queries to SQL Server. One line can pull a whole table into memory just to show ten rows. In both cases EF Core is doing exactly what the code asked for. The problem is the SQL that the code turns into.

Here are five patterns behind a lot of slow EF Core code, plus the one habit that catches all of them.

First: LINQ isn't run as C

When you write a LINQ query against a DbSet, EF Core doesn't run your lambdas. It reads the query as an expression tree and translates it into SQL. Nothing hits the database until you ask for results, with ToList, First, foreach and the like.

So asking "is my C# fast?" doesn't help much. The useful question is: what SQL did this become?

See the SQL before you guess

One line in your context options logs every command EF sends (Simple Logging):

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);

For a single query, ToQueryString() returns the SQL as a string without running it (available since EF Core 5.0):

var sql = query.ToQueryString();

Count the queries and look at the columns. Each fix below starts there.

Trap 1: N+1

var orders = await db.Orders.ToListAsync();     // 1 query
foreach (var o in orders)
    Console.WriteLine(o.Customer.Name);         // +1 query per order

With lazy loading turned on, every o.Customer access is a separate round trip. 100 orders means 101 queries. Lazy loading is opt-in: you get it from the Microsoft.EntityFrameworkCore.Proxies package and UseLazyLoadingProxies(). Once it's on, it hides this cost from you. The docs warn about it directly: lazy loading makes the N+1 problem very easy to trigger, and they recommend avoiding it.

Fix: ask for what you need up front. A projection becomes a single query with a JOIN:

var rows = await db.Orders
    .Select(o => new { o.Id, CustomerName = o.Customer.Name })
    .ToListAsync();                              // 1 query, with a JOIN

Use Include(o => o.Customer) if you really need the whole entity. Also watch for the same trap without lazy loading: a query inside a foreach.

Trap 2: the whole table

var big  = db.Orders.ToList().Where(o => o.Total > 1000);   // whole table
var good = db.Orders.Where(o => o.Total > 1000).ToList();   // WHERE in SQL

ToList() runs first, so the first line selects every row and filters in memory. In the second line, the filter becomes a WHERE clause. The lambda is identical, but the query is not.

There's a sneakier version:

IEnumerable<Order> orders = db.Orders;
var big = orders.Where(o => o.Total > 1000).ToList();       // whole table, again

Once the DbSet is typed as IEnumerable<T> (a variable, or a method parameter), Where resolves to the in-memory LINQ operator, and EF never sees the filter. Keep it IQueryable until you're done filtering.

EF Core does protect you from the accidental version. Since 3.0, an expression it can't translate, anywhere except the final projection, throws instead of silently running on the client. It can't protect you here, because here you explicitly asked for the whole table.

Trap 3: loading more than you show

A list page needs two columns, and db.Orders.ToList() brings back all of them. EF also tracks every entity it loads. As the docs explain, it keeps an identity dictionary and a snapshot per entity, so it can detect changes when you call SaveChanges. That costs time and memory.

// read-only list: just the columns
var rows = await db.Orders
    .Select(o => new OrderRow(o.Id, o.Total)).ToListAsync();

// read-only, full entities: skip the tracking
var orders = await db.Orders.AsNoTracking().ToListAsync();

A projection with no entity types in the result isn't tracked at all. If you need full entities but won't save them, add AsNoTracking().

How much does it matter? In Microsoft's own benchmark (10 blogs with 20 posts each), the no-tracking query took about 30% less time (993 µs vs. 1,415 µs) and allocated almost 40% less memory (233 KB vs. 380 KB). That's a small query, and the difference is still real.

Trap 4: cartesian explosion

var blogs = await db.Blogs
    .Include(b => b.Posts)
    .Include(b => b.Contributors)
    .ToListAsync();

Two collection Includes at the same level become one SQL query with two JOINs, and the database returns a cross product. The docs' example: a blog with 10 posts and 10 contributors comes back as 100 rows. EF Core logs a warning when a query loads multiple collections and you haven't configured a splitting mode, so read the log.

Fix: .AsSplitQuery() sends one query per collection instead of one big JOIN. It comes with trade-offs: there's an extra round trip per query, and if someone writes in between, the queries don't see one consistent snapshot. Split when the JOIN explodes, not everywhere.

Trap 5: the index killer

db.Users.Where(u => u.Email.ToLower() == email)

WHERE LOWER([u].[Email]) = @email

EF translates ToLower faithfully, as a function wrapped around the column. When a query filters on an expression over a column, a simple index can't be used. On SQL Server you usually didn't need it anyway: the default server collation for an English (US) install, SQL_Latin1_General_CP1_CI_AS, is case-insensitive.

The same idea applies to StartsWith and EndsWith: on SQL Server, the first can use an index on the column and the second can't.

A slow page? Go in this order

Log the SQL.
Count the queries. More than a few for one page? Look for N+1.
Check rows and columns. Are you loading the whole table, every column, or a cartesian explosion?
Open the query plan and look for a scan on a column you indexed.

EF Core doesn't make your query slow. It sends exactly the SQL you described, so read that SQL before you blame the ORM.

What's the most queries you've ever found behind one page?

I make Vlad's Stack: short explainers on how the tools you use every day actually work, for people who write code. VIDEO_CHANNEL_URL

Heartbleed: One Unchecked Length, Two Years, Half a Million Websites (and the C# Version)

VLAD — Thu, 29 Oct 2026 16:28:13 +0000

In April 2014, about half a million trusted websites had the same bug. Ask them the right way, and they'd hand you up to 64 KB of their memory: passwords, session cookies, private messages, sometimes the private key that protects the whole site. The attacker didn't break in. They sent one small message and lied about one number.

This post walks through Heartbleed using the primary sources: the OpenSSL advisory, the commit that added the bug, the commit that fixed it, and the RFC it was supposed to implement. At the end there's the part that matters for .NET developers, because the same mistake can still happen in safe C#, just more quietly.

The heartbeat

When you see the lock in your browser, your connection is protected by TLS. In 2014, a huge part of the web did that locking with OpenSSL, the free, open-source library behind Apache and nginx.

In early 2012, OpenSSL 1.0.1 added the heartbeat extension, from a new standard, RFC 6520. The idea is simple. A secure connection can sit idle for a while, so one side asks "are you still there?", and the other side answers. The request carries a small payload and says how long it is. The response must echo that payload back.

Say the payload is the word PING, four bytes. The server copies those four bytes into its answer and sends them back. That's a heartbeat.

One number nobody checked

Now, what if the request lies? It sends PING, four bytes, but claims the length is 64,000.

Here's the vulnerable function from OpenSSL 1.0.1f (ssl/t1_lib.c, tls1_process_heartbeat), trimmed:

hbtype = *p++;
n2s(p, payload);   /* read the length the client claims */
pl = p;            /* pointer to the payload */
/* ... */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);   /* copy `payload` bytes, trusting the client */

payload comes straight from the attacker's message. Nothing compares it with the number of bytes that actually arrived. So memcpy starts at the four real bytes and keeps going, into whatever sits next in the server's heap: other people's requests, their passwords and cookies, sometimes key material.

The length field is two bytes, so the largest value is 65,535: about 64 KB per heartbeat. And nothing limited the number of heartbeats. As heartbleed.com put it, the 64 KB limit applies to a single heartbeat, not to the attack.

Worst of all, it was silent. Exploiting it left nothing abnormal in the logs.

The irony is that the standard already said what to do. RFC 6520: if the payload_length of a received message is too large, the message must be discarded silently. The code just never did that.

Two years in plain sight

The heartbeat code was written by one of the authors of the heartbeat RFC. A core OpenSSL developer reviewed it and committed it on December 31, 2011, New Year's Eve. The author later said publicly that he missed a length check, the reviewer missed it too, and it wasn't deliberate.

OpenSSL 1.0.1 shipped on March 14, 2012, with the heartbeat on by default. Then it sat there through 2012 and 2013, on servers all over the world. "Given enough eyeballs, all bugs are shallow" is a nice line, but plenty of people used this code and very few read it.

Two teams, one week

In early 2014, Neel Mehta of Google Security was auditing OpenSSL. He found the missing check, and it was reported privately to the OpenSSL team on April 1, 2014. On April 3, the Finnish security company Codenomicon found the same bug independently. They gave it a name, a bleeding-heart logo and its own website.

On April 7, OpenSSL published the advisory and version 1.0.1g. The fix is exactly what the RFC asked for:

if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0; /* silently discard per RFC 6520 sec. 4 */

Netcraft checked that week: about 17.5% of SSL sites with trusted certificates had the heartbeat extension enabled, around half a million certificates.

What leaked

Patching stopped new leaks, but nobody could know what had leaked before, because there was no trace in the logs.

The scariest question was the private key. Cloudflare first concluded that stealing it was "at least extremely hard and, likely, impossible", and put up a vulnerable server as a public challenge. About nine hours later, two people had extracted its key; one of them sent at least 2.5 million requests. Cloudflare updated its post: they had been wrong. So patching wasn't enough. Affected sites had to revoke their certificates and get new keys.

In Canada, the tax agency took its online services down in the middle of tax season. It still wasn't fast enough: the agency reported that about 900 social insurance numbers were taken through Heartbleed, over a window of about six hours.

Who was holding it up

Then came the second question: who pays for OpenSSL?

Almost nobody. In a post from April 12, 2014, Steve Marquess of the OpenSSL Software Foundation wrote that it typically received about $2,000 a year in donations. Most of its money came from support contracts and consulting, and only one team member worked on it without another full-time job. In the week after the news, about two hundred people donated, mostly $5 or $10, around $9,000 in total.

On April 24, 2014, the Linux Foundation launched the Core Infrastructure Initiative, with companies including Google, Microsoft, Amazon and Facebook each pledging at least $100,000 a year for three years. OpenSSL was the first project funded.

Could this happen in C#?

The classic version, mostly no.

A C# array knows its own length. Read past the end and you get an IndexOutOfRangeException, not your neighbor's data.
A new array starts out zero-initialized, so there's no old secret sitting in it.
Windows itself wasn't affected out of the box: it uses its own TLS stack, SChannel, not OpenSSL, as Microsoft said at the time.

But modern .NET has one place where the old danger comes back: ArrayPool<T>. To avoid allocations, you rent a buffer and give it back when you're done, so the next caller gets the same array. The docs for Rent say two things:

The returned array is at least minimumLength long. It can be bigger.
The returned array may not be zero-initialized. It can still hold whatever the previous renter left in it.

So this is a small Heartbleed, written entirely in safe code:

byte[] buffer = ArrayPool<byte>.Shared.Rent(256);
try
{
    int written = WriteReply(buffer);      // writes, say, 40 bytes
    await stream.WriteAsync(buffer);       // BUG: sends buffer.Length bytes,
                                           // including old data from another request
}
finally
{
    ArrayPool<byte>.Shared.Return(buffer);
}

The fix is the same idea as OpenSSL's: only send what you actually wrote.

await stream.WriteAsync(buffer.AsMemory(0, written));

And the closer cousin: trusting a length the client sent you, and slicing that much out of a pooled buffer. If the claimed length is smaller than the rented array, nothing throws. You just copy out bytes that were never part of this request. Check the claimed length against the bytes you actually received, and if it doesn't match, drop the message.

If a pooled buffer ever holds secrets, Return also takes a clearArray flag:

ArrayPool<byte>.Shared.Return(buffer, clearArray: true);

What to take from it

Every number from outside is a claim, not a fact. Lengths, counts, offsets: check them against what you actually received.
No trace in the logs doesn't mean nothing happened. With Heartbleed, everyone had to assume the worst and rotate keys.
The code you depend on is maintained by real people. Sometimes very few of them.

What's the one open-source library your app can't live without, and do you know who maintains it? Tell me in the comments.

I make Vlad's Stack: short explainers and stories about how the tools you use every day actually work, for .NET and full-stack developers. The channel is here.

Your AI Coding Agent Never Reads Your Whole C# Solution

VLAD — Thu, 29 Oct 2026 11:55:05 +0000

You ask an AI agent to fix a bug in your C# solution. It never reads the whole solution. It searches, opens a few files, and decides from those. So when it gets it wrong, the reason is usually a file it never opened.

This post walks through what the agent reads first, how it hunts for the rest, the three places a .NET solution hides code from it, and the one file that fixes most of it. I use Claude Code as the concrete example because its behavior is documented, but the mechanics apply to most agents.

An agent is a model in a loop

An agent works in a loop: gather context, take an action, check the result, then go around again. The Claude Code docs describe exactly these three phases, and they're explicit about who does what: the model reasons, and the harness around it provides the tools and manages the context the model sees.

So the model never touches your disk. It asks for a file, the tool reads it, and the text goes back into the conversation.

Why it doesn't just read everything

Everything the agent reads lands in its context window, which Anthropic's docs call the model's working memory. Current Claude models have a 1M-token window. That sounds like enough for a whole solution.

But more isn't better. The same docs say that as the token count grows, accuracy and recall degrade, and they give it a name: context rot. So a good agent has to be picky about what it loads.

What it reads first

Not your code. An instruction file.

In Claude Code, that's CLAUDE.md.
Many other agents (Codex, Copilot's coding agent, Cursor, Gemini CLI and others) read AGENTS.md, which describes itself as a README for agents.

That file is loaded at the start of every session, before you type a word. Claude Code also sees your git state: the current branch, uncommitted changes and recent commits. Everything else, the agent has to go and find.

How it finds the rest

Pretty much the way you would on a new team:

File names. Show me every project file in this solution.
Text. Where does OrderService appear?
Read. Open the two or three files that look right.

Glob  **/*.csproj
Grep  "OrderService"
Read  Orders.Api/OrderService.cs

Anthropic's engineering team calls this just-in-time context: Claude Code uses glob and grep to pull files in as it needs them, rather than building a big index up front. CLAUDE.md is the exception: it's put into context right away.

Names are most of the clue

The same article points out that folder hierarchies and naming conventions are real signals for an agent. To you, an OrderService in a tests project and one in the API project are obviously different things. To the agent, the folder and the name are most of what it has.

In .NET, you get a free map: the .sln file and the .csproj files, which say which project references which. Good names make the search work. Vague names make it guess.

Where it gets lost in a .NET solution

1. Too many hits

Search for Order in a big solution and you get hundreds of lines: entities, DTOs, tests, migrations. Every file the agent opens costs context, so it opens the first few that look right. If the one that matters was result number forty, it never sees it.

2. Code wired by convention

EF Core lets you move each entity's configuration into its own class and then apply every configuration in an assembly with one line:

public class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> b)
        => b.HasKey(o => o.Id);
}

// AppDbContext.OnModelCreating
modelBuilder.ApplyConfigurationsFromAssembly(
    typeof(AppDbContext).Assembly);

Nothing in that last line says Order. An agent that reads your DbContext to understand how Order is mapped won't see it there, and can decide there's no configuration at all. The link only exists at runtime. The same goes for anything registered by scanning an assembly.

3. Code that isn't on disk

Source generators write C# at compile time and add it to the compilation. .NET itself uses them, for example for System.Text.Json and regular expressions.

By default, that generated code lives only in memory, inside the compiler. So the agent searches your folders for a method the compiler can see, and it isn't there. Setting EmitCompilerGeneratedFiles to true in the project file writes the generated files out under the obj folder, where they can be opened.

<PropertyGroup>
  <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
</PropertyGroup>

The good news: the compiler is on your side

The agent doesn't have to guess for long. It can run dotnet build, and the compiler answers with the exact file, the exact line, and what's wrong:

OrderService.cs(42,17): error CS1061: 'Order' does not contain a definition for 'Total'

A strong type system turns a wrong guess into an error message, fast. That's the "check the result" step of the loop, and C# gives it a lot to work with.

You can take it one step further. Claude Code has a C# code intelligence plugin (csharp-lsp, backed by csharp-ls) that connects it to a language server. With it, the agent finds definitions and references by symbol instead of by text, and sees type errors right after each edit. It isn't on by default; you install it.

The one file that fixes most of it

Write the instruction file the way you'd brief a new teammate:

A map of the solution: which project does what.
Build and test, one command each.
The traps: what's wired by convention, and where generated code comes from.

## Solution map
- Orders.Api: HTTP endpoints, no business logic
- Orders.Core: domain and services
- Orders.Data: EF Core, configs applied from assembly

## Commands
- build: dotnet build Orders.sln
- test:  dotnet test Orders.sln

## Watch out
- JSON contracts come from a source generator
- Handlers are registered by assembly scan

It sits in the context for the whole session, so keep it short.

There's one more reason it matters. In a long session the context fills up, and Claude Code compacts the conversation into a summary. The docs warn that detailed instructions from early in the conversation may be lost in that summary, and their advice is to put persistent rules in CLAUDE.md. Rules that must stick go in the file, not in the chat.

Three rules

Names that search well.
A file that maps your solution.
A build that tells the agent, fast, when it's wrong.

An AI agent doesn't know your solution. It searches it, like a new hire on day one. Your job is to make that search easy.

What's in your instruction file right now? Or don't you have one yet? Tell me in the comments.

I make Vlad's Stack: short explainers on how the tools you use every day actually work, for .NET and full-stack developers. The channel is here.

A hash map is just an array that computes its own index

VLAD — Wed, 28 Oct 2026 11:42:18 +0000

A map with a million keys answers a lookup just as fast as a map with ten. No loop. No searching. Your program jumps straight to the answer.

That's not magic, and it isn't a tree. It's one very old trick, plus two failure modes that most people never hear about.

Prefer to watch? Full walkthrough with the bucket animation:

Arrays are the fast part

Start with the one thing computers are genuinely fast at: an array. Ask for item number five and nothing is searched. The machine multiplies the index by the element size, adds it to the start address, and lands on the exact spot in memory. Item five and item five million cost the same.

The catch is that arrays only take positions. You don't think in positions — you want the value stored under "email", or under a user ID, or under a whole string of text.

So the real question is: how do you turn a key like "email" into a position?

The hash function

A hash function takes anything — a word, a sentence, an object — and gives back a number. Two properties matter:

Deterministic. Same key in, same number out, every time.
Well spread. Change one letter and the result isn't close to the old one, it's unrecognizable. A hash that put similar keys near each other would pile them up in the same place.

That number is usually huge, much bigger than your array. So you do the simplest possible thing: take the remainder.

hash("email")        = 3,742,909
3,742,909 % 8        = 5

Now you have a position. Each slot of that array is called a bucket.

Look at what just happened. You didn't search for the key — you computed where it lives. Writing is hash, remainder, store. Reading is hash, remainder, load.

The whole idea, in code

const buckets = new Array(8)

const slot = (key) => hash(key) % buckets.length   // "email" → 5

buckets[slot("email")] = "vlad@stack.dev"          // write
buckets[slot("email")]                             // read

There's a problem hiding in that one line. The hash space is huge, the array is small. So sooner or later, two different keys produce the same slot.

Collisions are normal

That's a collision, and it isn't an edge case — with 8 slots it happens almost immediately.

So a bucket doesn't hold a bare value. It holds pairs: the key and the value. On a lookup you jump to the bucket, then compare keys inside it. Usually there's one pair. Sometimes two. That's also why a map has to store your key at all — otherwise it could never tell two collided keys apart.

There are two ways to handle the collision, and languages pick sides:

Chaining — keep a small list inside the bucket and walk it.
Open addressing — no list; if the slot is taken, step to the next one until you find a free seat. CPython's dict works this way (see the comment at the top of Objects/dictobject.c — an implementation detail, not a language guarantee).

Either way the shape is the same: land close to the answer, then take a step or two.

So what does "constant time" actually mean?

One hash. One jump. A tiny compare. It isn't zero work — it just doesn't get worse as the map grows. The Java docs put a condition on it: constant-time performance for get and put, assuming the hash function disperses the elements properly among the buckets.

Hold on to that "assuming". It's where both failure modes live.

Load factor: the resize you don't see

Keep adding keys to the same small array and the buckets fill up. Those little lists get long, and comparing one by one stops being cheap. So a map watches how full it is — that ratio is the load factor.

In Java, a HashMap starts with 16 buckets and a load factor of 0.75. Cross that line and the table is rebuilt with roughly twice as many buckets, and every existing key is re-slotted.

Which means one unlucky insert does the work of the entire map. The average stays fast. That one call doesn't. If you know you're about to load a million entries, size the map up front.

When O(1) is a lie

Now the interesting failure. Imagine every key you insert lands in the same bucket. One long list; every lookup walks it. Your constant-time map is now a linear scan.

That can happen by accident with a bad hash — and it can be done to you on purpose. An attacker who knows your hash function can send keys engineered to collide, turning cheap requests into expensive ones. Python's answer is to salt the hash of str and bytes with a random value at startup, explicitly as protection against that denial of service.

The key that disappears

This one is your own fault, and it's a classic.

You store a value under a key. Then you mutate that key object. Its hash changes with it. The map now computes a different slot, looks there, and finds nothing — while your entry sits in the old bucket, unreachable.

Use keys that can't change: a string, a number, a frozen/immutable object.

And no, it has no order

A hash map scatters keys by their hash, not by when you added them, so iteration order is whatever the buckets happen to hold.

Python is the exception you've probably been relying on: since 3.7, a dict preserves insertion order as a language guarantee. Java's HashMap promises nothing of the sort. If you need order, use the type that promises it.

Three rules

Keys that don't change.
A hash that spreads keys out.
Enough room that the map isn't constantly resizing.

Get those right and it behaves like magic. Get them wrong and it quietly becomes a list.

A hash map isn't magic and it isn't a tree — it's an array that already knows where you put things.

What's the worst hash-map bug you've hit — the key that vanished, or the resize that froze your app? Tell me in the comments, I read them.

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. The full video walkthrough is above.

Your database says "saved" before it touches the table. Here's why that's safe.

VLAD — Tue, 27 Oct 2026 21:31:22 +0000

When your database says your transaction is saved, your row usually isn't in the table file yet. Pull the power cord in the middle of a write, and you still lose zero committed rows.

That's not luck. It's one file doing one job: the write-ahead log (WAL).

Prefer to watch? Full walkthrough with the crash-and-replay animation:

The obvious way to save data — and why it fails

The obvious design: you run an UPDATE, the database finds the right spot in the table file, and overwrites the value there. Simple. It has two problems.

It's slow. One small change can touch the table and two or three indexes — pages scattered all over the disk. Every one of them would have to be forced to disk before the database could say "saved."
It's unsafe. If the power dies halfway through, the table might have the new value while the index still has the old one. Now the database disagrees with itself, and nothing tells you.

Write it down first

So databases do something that sounds backwards: before they change the table, they write down what they're about to change. One short record, added to the end of a log file — "account 1, balance minus 100."

That's the write-ahead part: the log is always written ahead of the data. The PostgreSQL docs put the rule plainly: changes to data files may only be written after the log records describing them have reached permanent storage.

Think of a waiter with a notepad. They don't run to the kitchen after every word — they write the order down first. If they trip and drop the plates, the order is still on the pad, and the kitchen just cooks it again.

One transfer, step by step

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Each UPDATE changes a page in memory and adds a record to the log.
On COMMIT, the database forces only the log to disk.
As soon as that's safe, you get your "OK."
The changed table pages are still in memory. They'll reach the disk later, in the background.

Why it's also fast

The log only grows at the end, so writing it is one straight, sequential write. The table pages are scattered across the disk. So you pay for one cheap write at commit time and push the expensive, scattered writes to later. The Postgres docs make the same point: because the WAL is written sequentially, syncing it costs much less than flushing the data pages.

Pull the plug: crash recovery

Right after a commit, your saved data lives in two places: the log (on disk) and the updated table pages (in memory). Now the power dies.

Everything in memory is gone.
The table file on disk is old — it still says the money never moved.
The database starts up again, opens the log, and replays it, record by record: minus 100, plus 100, commit.
The table catches up. Zero committed rows lost.

Postgres calls this roll-forward recovery, or REDO. Crash recovery is just the database reading its own notes.

What about a transaction that never committed?

Say the power dies between the two updates. There's no commit record in the log for that transaction, so after the restart its changes count as if they never happened. You never get half a transfer — all of it, or none of it.

Checkpoints: why the log doesn't grow forever

If every change goes into the log, doesn't the log grow forever? No. Every so often the database runs a checkpoint: it writes all the changed pages from memory into the table files. Everything before that point is now safely in the table, so the old log can be recycled.

In Postgres, a checkpoint starts every 5 minutes by default, or sooner if the log is about to pass 1 GB (checkpoint_timeout and max_wal_size). It's also why recovery is fast: it only replays from the last checkpoint, not from the beginning of time.

The torn page

One nasty detail almost breaks all of this. A Postgres page is 8 kB. If the power dies while that page is being written, the disk can end up with a torn page — half new data, half old. A small log record describing one row change can't repair a page that's already broken.

So Postgres does something clever: the first time a page changes after a checkpoint, it writes a full copy of that page into the log (full_page_writes, on by default). If recovery finds a torn page, it starts from that clean copy and replays the rest on top.

One log, many jobs

The log isn't just for crashes.

Replication. A replica is just another server replaying the same log. Postgres streaming replication ships these WAL records over the network. A replica that's "behind" is simply at an older position in the log.
Positions. Every record has a position called an LSN (log sequence number). You can ask Postgres for the current one:

SELECT pg_current_wal_lsn();

Other databases. It's not a Postgres quirk. MySQL's InnoDB has a redo log, and SQLite has a WAL mode. Same idea everywhere: write it down first.

What this means for your code: every commit waits for the disk

Even if you never build a database, this changes how you write to one. Every commit waits for the log to reach the disk — once per commit.

-- autocommit: one commit per row
INSERT INTO events (payload) VALUES ('a');   -- × 10,000

-- one transaction: one commit
BEGIN;
INSERT INTO events (payload) VALUES ('a');   -- × 10,000
COMMIT;                                      -- one wait

Insert 10,000 rows with one commit each and you wait for the disk 10,000 times. Wrap them in one transaction and you wait once. Same rows, same table. If your bulk import is slow, check your commits before you blame the inserts.

The setting that forgets

Because that wait is the slow part of every commit, Postgres lets you skip it:

SET synchronous_commit = off;

Your commit now returns before the log is on disk. It's faster — but if the server crashes, the most recent "saved" transactions can disappear. According to the docs, the risk window is at most three times wal_writer_delay (200 ms by default, so roughly the last 0.6 seconds).

Here's the difference that matters:

synchronous_commit = off risks losing the last few transactions, but what's left stays consistent. The docs call it data loss, not data corruption.
fsync = off means a system crash can corrupt the whole database.

One is a trade-off you can make on purpose, for data you can afford to lose. The other is a trap.

The takeaway

"Saved" doesn't mean it's in the table. It means it's in the log — and the log is enough to rebuild everything else.

What's the riskiest durability setting you've ever turned off, just to go faster? Tell me in the comments — I read them.

I make Vlad's Stack — how the tools you use every day actually work, for people who write code. The full video walkthrough is above; it's part of a short series on how databases work, next to how an index finds one row in a million.

Where null Came From, and Why C# Needed 17 Years to Push Back

VLAD — Tue, 27 Oct 2026 12:16:37 +0000

Object reference not set to an instance of an object. If you write C#, you've read that message more times than you can count. It's a NullReferenceException, and it goes back to a decision one man made in 1965. In 2009 he gave that decision a name: his billion-dollar mistake.

This is the story of where null came from, why it ended up in almost every language you know, and how C# pushed back without breaking existing code. The strange part comes first: the man who added null was trying to make programs safer.

The man who checked everything

Tony Hoare is best known for inventing Quicksort. In his 1980 Turing Award lecture he tells how he started. In August 1960 he became a programmer at Elliott Brothers, a small British computer manufacturer, and was soon asked to design a subset of ALGOL 60 for the company's next machine.

He says the first principle of that design was security. Every correct program should produce either a result or an error message you could understand in terms of your own source code. One consequence: every array subscript was checked at run time against the bounds of the array, every time.

That cost speed. Years later, the company asked its customers whether they wanted an option to switch the checks off for production runs. Hoare says they unanimously asked him not to, because they already knew how often those errors show up in real runs.

So this was someone who put safety before speed.

1965: one value that was easy to add

In 1965, Hoare was working with Niklaus Wirth on a successor to ALGOL 60. The proposal was published in 1966 as "A Contribution to the Development of ALGOL", and the language became known as ALGOL W.

One of its ideas was the record: a bundle of named fields, like a customer with a name and an address. With records came references, variables that point to a record instead of holding it.

Hoare wanted references to be completely safe. Each reference had a type, so a reference to a customer could only point to a customer, and the compiler would check that before the program ran. In the abstract of his 2009 talk he describes it as the first comprehensive type system for references in an object-oriented language.

But programs also need a way to say "nothing here". The last item in a list has no next item. So he added one special value that any reference could hold: null. By his own account, he couldn't resist the temptation, because it was so easy to implement.

What null breaks

The type says Customer. The compiler agrees. But the variable may hold null instead.

Customer c = FindCustomer(id);   // may return null
Console.WriteLine(c.Name);       // NullReferenceException at run time

The type makes a promise the program can't keep. In a safe language, the program stops with an error. In an unsafe one, it reads whatever happens to be in memory. Either way you find out late: not when you write the code, but when a real user hits that one path.

It spread everywhere

ALGOL W never became a big language, but the idea traveled. Wirth went on to design Pascal, which had the same thing under the name nil. C had its null pointer, and so did C++. Java got the famous NullPointerException. And in 2002, C# 1.0 shipped with the same design: null is the default value of every reference type. Declare a field, forget to set it, and it's null.

Two things are worth getting right here.

Myth: Hoare invented the empty value. Lisp already had NIL around 1960. What Hoare says he invented is the null reference: null inside a type system that was built to make references safe.

Myth: null has been shown to cost a billion dollars. Nobody measured it. It was his own rough estimate for forty years of errors, vulnerabilities and crashes, and he qualified it with "probably".

C# looks back

In 2008, Anders Hejlsberg, the lead designer of C#, was asked by Computerworld what he would do differently. He talked about null. His guess was that half of the bugs people run into in C#, and in Java too, are probably null reference exceptions. He wished the type system could say that a parameter may never be null, and have the compiler check it.

The interesting part is that C# had already done this for half of its types. C# 2.0, in 2005, added nullable value types:

int a = null;    // compile error
int? b = null;   // fine: the ? is part of the type

That's the honest design. Null is allowed, but only where the type says so. It just didn't exist for classes.

Other languages went first

Newer languages started from that idea. In Kotlin, a String can never hold null and a String? can. Assigning null to the plain one doesn't compile. Kotlin's documentation on null safety names the billion-dollar mistake as the thing it's designed to reduce.

TypeScript got --strictNullChecks in version 2.0, released in September 2016. Before that, null and undefined were valid values of every type. The lead designer of TypeScript is the same Anders Hejlsberg.

So the idea was proven. The hard part was bringing it to a language with 17 years of existing code.

C# 8: nullable reference types

In November 2017, Mads Torgersen, the C# lead designer, published the plan in "Introducing Nullable Reference Types in C#", quoting Hoare's billion-dollar mistake. The feature shipped in C# 8.0 in September 2019.

With the feature on, the meaning of your existing types changes:

string name = null;          // warning: plain string means "not null"
string? middleName = null;   // fine: this one may be null

Console.WriteLine(middleName.Length);   // warning: possible null dereference

Three design choices made this possible without breaking the world:

Warnings, not errors. Old code keeps compiling.
Opt-in. At first you had to turn it on yourself. Today, recent .NET project templates set <Nullable>enable</Nullable> for you.
No runtime change. string and string? are the same type at run time. Only the compiler sees the difference.

Where null still hides

Null isn't gone from C#. The same documentation lists the places where a non-nullable reference can still hold null with no warning:

string[] names = new string[3];   // every element is null, no warning

struct Student { public string FirstName; }
Student s = default;              // s.FirstName is null, no warning

And there's the null-forgiving operator, !. It tells the compiler "trust me, this isn't null". Every one you write is a place where the compiler stops protecting you.

Why it took 54 years

In 1965, one special value was the easy way to say "nothing here". And a language can't take back its defaults once millions of programs depend on them.

The fix was never to delete null. It was to make the type tell the truth about it. From ALGOL W to C# 8, that took 54 years.

Tony Hoare died on March 5th, 2026, at 92. He gave us Quicksort, and he had the honesty to name his own mistake.

Is nullable turned on in your oldest C# project? And how many warnings did it give you? Tell me in the comments.

I make Vlad's Stack, stories and explainers about how the tools you use every day actually work, for people who write code: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

Ariane 5, Flight 501: The Exception That Destroyed a Rocket

VLAD — Sat, 10 Oct 2026 21:57:58 +0000

On June 4th, 1996, Europe launched Ariane 5 for the first time. About forty seconds after the flight sequence began, the rocket veered off course, broke up and destroyed itself. The engines were fine. The weather was fine. What failed was a data conversion in code that had no reason to be running.

This story gets retold a lot, usually as "an integer overflow blew up a rocket". The inquiry board's report (chaired by Jacques-Louis Lions, published July 19th, 1996) tells a more useful story. The check actually worked. What nobody had decided was what should happen when it fired.

The box that knows which way is up

To fly straight, a rocket has to know which way it's pointing and how it's moving. On Ariane, that's the job of the inertial reference system, called SRI in the report after its French name. It has laser gyros, accelerometers and its own computer. It sends attitude and velocity data to the main on-board computer, and that computer steers by swiveling the engine nozzles.

Ariane 5 carried two SRIs with identical hardware and identical software. One was active, the other was a hot standby. If the active one failed, the main computer would switch to the backup.

The report also notes that the SRI design, and especially its software, was practically the same as on Ariane 4. It had flown for years. Nobody saw a reason to change software that worked.

Code that had no job

Before launch, the SRI aligns itself: it finds the direction of gravity and finds north from the rotation of the Earth. That only makes sense while the rocket stands still on the pad.

On Ariane 4, the alignment function kept running for a while after the SRI went into flight mode. That was on purpose. If a countdown was held in its last seconds, a full realignment took 45 minutes or more, and the launch window could be lost. Keeping alignment alive a little longer let the team restart the countdown quickly. According to the report, the feature was used once, in 1989.

Ariane 5 had a different preparation sequence and didn't need this. The requirement was kept anyway, to stay in common with Ariane 4. So on Ariane 5 the alignment code ran for about 40 seconds after lift-off, computing values that no longer meant anything.

The number that couldn't get too big

Inside the alignment code there's a value the report calls BH, for horizontal bias. It's related to the horizontal velocity the platform senses. It was held as a 64-bit floating point number, and at one point the Ada code converted it to a 16-bit signed integer. A 16-bit signed integer tops out at 32,767.

The developers knew conversions like this were a risk. The report says they analysed every operation that could raise an exception and found seven variables at risk. But there was a constraint: a maximum workload target of 80% for the SRI computer. So they protected four of the seven conversions. The other three, including BH, were left unprotected, because the reasoning was that those values were either physically limited or had a large safety margin.

For Ariane 4 that reasoning was correct. But:

The justification wasn't in the source code. The report says the assumption, although agreed, was in practice hidden from any external review.
The Ariane 5 trajectory data was not part of the SRI's requirements and specification.
Ariane 5 builds up horizontal velocity about five times faster than Ariane 4 in the early part of the flight.

What happened in flight

The rocket flew normally until about 36 seconds after the start of the main engine ignition sequence. Then BH exceeded what 16 bits can hold. The conversion raised an Operand Error, and nothing in the code handled it.

For an unhandled exception, the SRI specification said: indicate the failure on the databus, store the failure context in memory, and shut the processor down. The report explains where that rule came from. The programme was designed around random hardware failures. If a part breaks at random, you switch the unit off and the backup takes over.

This wasn't random. The backup ran the same software with the same inputs. It had already stopped, one 72-millisecond data cycle earlier, for the same reason. As the report puts it, two critical units that were still healthy got switched off.

Then it got worse. The failed active SRI put a diagnostic bit pattern on the bus, and the main computer interpreted it as flight data. Based on that, it commanded full nozzle deflections on both solid boosters and then on the main engine. The rocket turned at an angle of attack of more than 20 degrees, the boosters started to separate from the core stage, and that correctly triggered the self-destruct system at about 4 km altitude.

The debris fell on about 12 square kilometres of swamp and savanna near the launch site. Both SRIs were recovered, and the failure context was read out of their memory. The four Cluster science satellites on board were lost. The loss is widely reported at about $370 million; that figure is not from the inquiry report.

The same line in C

Here's the part that matters for those of us who will never write flight software. In C#, the same conversion is one cast:

double bh = 40000.0;

short a = (short)bh;            // compiles without a warning
short b = checked((short)bh);   // throws OverflowException

By default, C# evaluates non-constant expressions in an unchecked context. For a double to integer conversion that's out of range, the documentation says the result is an unspecified value of the destination type. No exception, no warning. Your program keeps going with a number that means nothing. In a checked context, the same cast throws OverflowException.

So which one is safer? It's tempting to say "checked, obviously". But Ariane's code was the checked one. The conversion raised the error, and the error is what shut both computers down. The value itself wasn't needed any more. The board points out that the SRIs could have kept providing their best estimates of the attitude data instead.

That doesn't make silent garbage the right answer. It means a check is only half a decision. The other half is what the system does when the check fails: crash, retry, fall back to a safe value, or keep going in a degraded mode. On flight 501, that half had been decided years earlier, for a different kind of failure.

What to take from this

The board made 14 recommendations. Three ideas from the report apply to ordinary code:

Code that isn't needed shouldn't be running. Recommendation R1 is exactly this: switch off the alignment function immediately after lift-off, and more generally, run no software function during flight unless it's needed.
Reused code brings its old assumptions with it. "This value can't get that big" was true for Ariane 4. It wasn't visible in the code, and nobody tested it against Ariane 5's trajectory. The report notes that a ground test with simulated Ariane 5 flight data would have exposed the failure. That test was never run on the SRI.
A backup that runs the same code is no backup against a bug. Redundancy protects you from random hardware faults. Two copies of the same software fail the same way at the same moment.

There's also one position in the report that still sounds bold. The project had treated software as correct until shown to be at fault. The board argued for the opposite view: assume software is faulty until accepted best-practice methods can demonstrate that it's correct.

Ariane 5 recovered. According to ESA, it flew 117 times between 1996 and 2023, and it launched the James Webb Space Telescope. The Cluster satellites were rebuilt and launched in 2000 on Soyuz rockets.

What's the oldest assumption you've found hiding in code you reused? Tell me in the comments.

I make Vlad's Stack, stories and explainers about how the tools you use every day actually work, for people who write code: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

The Court Order Behind C#: How Two Keywords Started a New Language

VLAD — Tue, 06 Oct 2026 15:09:50 +0000

On November 17th, 1998, a federal judge in San Jose gave Microsoft ninety days to change its Java tools. The court papers in that case talk about two words that C# developers still type every day: delegate and multicast.

This is the story of how a lawsuit over Java ended up producing C#. It's told from the court records, the documents the companies published at the time, and what C#'s lead designer, Anders Hejlsberg, has said in public.

The man from Borland

In the early eighties, Anders Hejlsberg wrote a small, very fast Pascal compiler. Borland sold it as Turbo Pascal. Later, at Borland, he led the team that designed Delphi. In Delphi you drew a window, dropped a button on it, and wrote the code that should run on click.

Keep that button in mind. The whole story turns on one question: how do you connect a button to a piece of your code?

In 1996, Hejlsberg left Borland and joined Microsoft (Artima interview bio). He wasn't the only one to leave. In May 1997, Borland sued Microsoft, saying it had hired away at least 34 of its people in 30 months (EE Times). The two companies settled in September 1997, and the terms were never made public.

Microsoft's Java

In the mid-nineties, Java promised "write once, run anywhere". In March 1996, Microsoft signed a license with Sun Microsystems, the company that owned Java, and built its own Java for Windows: its own virtual machine and a developer tool called Visual J++. Hejlsberg became an architect on Visual J++ and on a Windows library for it, the Windows Foundation Classes (WFC).

Microsoft's Java could call Windows directly. Code that did that only ran on Windows.

Sun sues

On October 7th, 1997, Sun sued Microsoft in federal court in San Jose. The charges included breach of contract, trademark infringement, false advertising and unfair competition (Sun's announcement, via MacTech). Sun said Internet Explorer 4.0 and Microsoft's Java SDK failed Sun's compatibility tests while still carrying the "Java Compatible" logo. It also said pieces were missing: JNI, the standard way for Java to call native code, and RMI, for calling objects on other machines.

Two new words

While the case moved through the court, Microsoft shipped Visual J++ 6.0. Its compiler understood two words that weren't in Java: delegate and multicast.

Here's the problem they solve. A button is written long before your code exists. When someone clicks it, it has to call one of your methods. So you need a way to hand the button a method and say: call this, later.

Java's answer, then, was an object. You wrote a small class that implements a listener interface and passed an instance to the button:

button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        System.out.println("Hello, world!");
    }
});

Microsoft's answer was the delegate: a reference that points straight at a method. You hand over the method itself, like a value. A multicast delegate holds a list of methods, so one click runs all of them.

If you write C#, you use this every day, even if you don't think about it:

button.Click += OnClick;      // add a method to the delegate's list
button.Click += LogClick;     // one click, both methods run

void OnClick(object sender, EventArgs e) => Console.WriteLine("Hello, world!");
void LogClick(object sender, EventArgs e) => Console.WriteLine("clicked");

The court described the J++ version precisely. When Microsoft's compiler met delegate and multicast, it generated classes that extend com.ms.lang.Delegate and com.ms.lang.MulticastDelegate, classes that only Microsoft's virtual machine had. The bytecode was valid, but it looked for classes no other JVM shipped (Sun v. Microsoft, 21 F. Supp. 2d 1109).

Sun says no, for the second time

Sun's Java team answered with a public white paper, "About Microsoft's 'Delegates'". It argued that bound method references were unnecessary and bad for the language, and that inner classes could do the same job.

Then it said something surprising. Sun had considered this exact idea in 1996. It had built working prototypes and thrown them away. And it made that decision in consultation with Borland, which already had bound method references in Delphi.

Delphi, the language Hejlsberg had led at Borland. The idea Sun turned down in 1996 was back, inside Microsoft's Java.

Ninety days

On November 17th, 1998, Judge Ronald Whyte granted Sun a preliminary injunction. Microsoft had ninety days to:

ship a Java runtime that supports JNI and passes Sun's tests;
make its compiler disable the Microsoft language extensions by default;
show a warning when a developer turned them on, saying the code might not run on other Java virtual machines;
and stop adding any new keywords or compiler directives to its Java tools.

Hejlsberg himself filed a declaration in the case. A later order cites it to explain that WFC, his Windows library, used the delegate and multicast keywords (87 F. Supp. 2d 992, Jan 2000).

While that order stood, Microsoft's Java couldn't get a single new language feature. The case went to the Ninth Circuit and back, and a new order came in January 2000. But Visual J++ 6.0 was the last version.

Project Cool

Around the start of 1999, Hejlsberg put together a small team to design a new language. Its working name was Cool, for "C-like Object Oriented Language". He has said the core design team was about six people, meeting three times a week for two hours (The Pragmatic Engineer). In 2001, he described the goal as the power and expressiveness of C++ with the ease of Visual Basic (CNET interview, via HPCwire).

This time, nobody else owned the language. Microsoft could add any keyword it wanted. So delegates went in, not as an extension but as a core part of the language. Multicast went in too, built into every delegate. And on top of it came a new keyword, event. Properties, events and a button wired straight to a method were built into the language from day one.

C# ships

June 26, 2000: Microsoft announced C# and submitted it to the standards body ECMA. An early preview followed at the Professional Developers Conference in Orlando, on July 11.
January 23, 2001: the Java case settled. Microsoft paid Sun $20 million, the 1996 license was terminated, and Microsoft could keep shipping its existing Java products for seven years.
December 2001: ECMA approved ECMA-334, the C# standard, based on a submission from HP, Intel and Microsoft.
February 13, 2002: Bill Gates launched .NET and Visual Studio .NET. C# shipped with them.

The twist

In April 2004, the two companies made peace. Microsoft paid Sun $700 million to settle antitrust issues and $900 million for patents (Microsoft announcement). Microsoft's Java virtual machine was retired for good at the end of 2007.

And Java? In 2014, Java 8 added lambdas and method references, so you could finally hand a button a method directly:

button.addActionListener(this::onClick);

It isn't the same thing as a C# delegate under the hood (Java still compiles it to an object that implements a functional interface). But it solves the problem Sun's white paper had called unnecessary.

Why C# exists

Microsoft wasn't allowed to change a language it didn't own, so it built one it could change. The next time you write += on an event, remember that the feature behind it was once at the center of a federal court case.

If Sun had said yes to delegates in 1998, would C# exist at all? Tell me what you think in the comments.

I make Vlad's Stack, stories and explainers about how the tools you use every day actually work, for people who write code: https://www.youtube.com/channel/UCUO8Uo5LsEy1b9eRkrH6JNg

DEV Community: VLAD

What async/await Actually Does in C# (and Where One .Result Costs You 3 Seconds)

The myth: async means another thread

Who waits for the database?

The compiler rewrites your method

What one await turns into

Where does the rest of the method run?

The .Result deadlock

ASP.NET Core: no deadlock, still slow

The fix

Two more traps

The JavaScript difference

What to look for in your code

LLM Tokens, Measured in C#: Why AI Can't Count the R's in Strawberry

What the model actually gets

Where tokens come from: byte pair encoding

The same sentence costs more in other languages

Numbers get cut too

Your code, and the expensive part

Why this matters

Every model has its own tokenizer

Counting tokens in .NET

Back to strawberry

The measurement program

Why TypeScript 7 Is Written in Go, Not C#: 43 Years of Anders Hejlsberg

A compiler from Denmark

Turbo Pascal, 1983

Delphi, 1995

C

TypeScript, 2012

The slow compiler

Why Go, not C

TypeScript 7

One idea, four languages

Isolation Levels: How the Last Item in Stock Gets Sold Twice

A transaction isn't a freeze

Read uncommitted: a price that never existed

Read committed: same SELECT, two answers

The lost update: where the two customers come from

Repeatable read: rows you read stay locked

Phantoms: 10 seats, 11 people

Serializable: lock the whole range

The whole dial

Same name, different behavior

What EF Core and .NET pick for you

A checklist for your own app

EF Core Isn't Slow. These 5 Query Patterns Are.

First: LINQ isn't run as C

See the SQL before you guess

Trap 1: N+1

Trap 2: the whole table

Trap 3: loading more than you show

Trap 4: cartesian explosion

Trap 5: the index killer

A slow page? Go in this order

Heartbleed: One Unchecked Length, Two Years, Half a Million Websites (and the C# Version)

The heartbeat

One number nobody checked

Two years in plain sight

Two teams, one week

What leaked

Who was holding it up

Could this happen in C#?

What to take from it

Your AI Coding Agent Never Reads Your Whole C# Solution

An agent is a model in a loop

Why it doesn't just read everything

What it reads first

How it finds the rest

Names are most of the clue

Where it gets lost in a .NET solution

1. Too many hits

2. Code wired by convention

3. Code that isn't on disk

The good news: the compiler is on your side

The one file that fixes most of it

Three rules

A hash map is just an array that computes its own index

Arrays are the fast part

The hash function

What one `await` turns into

The `.Result` deadlock