The Journey of Null: How It All Began

If you’ve been programming in C# for any length of time, chances are you’ve met the infamous NullReferenceException. It usually shows up at the least convenient moment, flashing its cryptic message: “Object reference not set to an instance of an object.”

I still remember my early brush with null—back in the C days, when a stray NULL pointer could bring everything crashing down. Later, in higher-level languages, the same ghost reappeared: calling a method on a variable that wasn’t really pointing anywhere. Each time it was both an ‘aha!’ moment and a ‘why does this even exist?’ moment.

It turns out, there’s a story behind that null — and it’s a long one. Back in 1965, Tony Hoare (a legendary computer scientist) introduced the idea of the null reference while working on the language ALGOL W. He later called it his “billion-dollar mistake”, because of the countless bugs, crashes, and vulnerabilities that have been caused by null references ever since.

But null wasn’t added as a prank on developers. At the time, it was a neat, simple solution: how do you represent “no value” in a system that always expects some value? Enter null — a placeholder that says this reference doesn’t point anywhere. Simple, efficient, but with hidden costs.

Over the decades, different languages have wrestled with this idea in different ways. C had NULL. C++ tried to patch over it with nullptr. Visual Basic used Nothing. And C# — well, C# inherited the problem but also gave us some clever tools to manage it. From the early days of runtime exceptions to the modern world of nullable reference types, C#’s journey with null has been full of lessons.

In this article, we’ll walk through that journey:

• where null came from,
• how C, C++, and VB treated it,
• and how C# has steadily evolved its null-checking features over the years.

By the end, I hope you’ll not only see why null became such a big deal, but also feel more confident about using C#’s modern null-safety features in your own code.

What is null, really?

Before diving into the history, it helps to pause and ask: what exactly is null?

At its core, null is a way of saying “this variable isn’t pointing to anything.” Think of a reference variable as a signpost. Most of the time, it points to a real object in memory. But sometimes, the signpost just points to… nowhere. That “nowhere” is null.

In practical terms:

• For reference types, null means the variable doesn’t reference an instance. You can declare a string variable, never assign it, and it happily sits as null until you try to use it.
• For value types (like int, double, bool), null traditionally wasn’t allowed. An int must always contain a number — 0, 42, -7 — but never “nothing.” (C# later introduced nullable value types, which we’ll get to in the timeline.)

Here’s a tiny illustration in C#:

string name = null;
Console.WriteLine(name.Length);

The crash happens because we’re asking for Length on a string that doesn’t exist. There’s no object behind that signpost, yet the program tries to walk the path anyway.

So null isn’t inherently evil — it’s just a placeholder for “no object here.” The trouble is what happens when we forget to check for it. That’s where decades of bugs, crashes, and “billion-dollar mistakes” enter the story.

The Original Idea: Why null Was Added

If null has caused so much pain, why was it introduced in the first place? The answer goes back to the mid-1960s, when programming languages were still finding their footing.

Tony Hoare, one of the giants of computer science, was working on a language called ALGOL W. He needed a practical way to represent an “empty” reference — a way for a variable that was supposed to point to an object to instead represent no object at all. The solution seemed elegant at the time: add a special value, null, that meant “this reference doesn’t point anywhere.”

In Hoare’s own words decades later, he called it his “billion-dollar mistake.” Why? Because while null was simple to implement and convenient for developers, it opened the door to an endless stream of bugs. Every time you dereference a variable, you now have to wonder: is it pointing to something real, or is it null? Forget that check, and the program explodes at runtime.

But to be fair, the decision made sense in the 1960s:

• Memory was scarce. Adding a dedicated “no object” marker was efficient compared to more complex alternatives.
• Programmer convenience. It was easier to say if (ptr == null) than to invent whole new types to represent “maybe an object, maybe not.”
• Language simplicity. A single sentinel value unified the concept of “nothing here,” instead of requiring every type to invent its own.

This simplicity was a blessing and a curse. The blessing: developers could write leaner code, and compilers were easy to build. The curse: programmers (and compilers) now had to account for a “missing object” everywhere.

It’s worth noting that other approaches were possible. Some later languages avoided null entirely by using option types (sometimes called Maybe<T>), forcing the programmer to explicitly handle the “no value” case. But in ALGOL W — and later in C, C++, and VB — the null reference was the default.

That decision set the stage for decades of runtime crashes and defensive code. Every language that followed had to deal with the legacy of null in some form.

How Early Languages Handled “Nothing”

Once null had been invented, every major language had to decide how to represent “no value.” Some kept it almost as-is, others tweaked it slightly — but all of them carried the same risks.

In C, the idea of “nothing” showed up as NULL. Under the hood, it wasn’t magical — just a macro, usually defined as 0 or ((void*)0). A pointer could be set to NULL to mean “it points nowhere.”

int *ptr = NULL;

Dereferencing such a pointer was dangerous: it triggered undefined behavior, often a crash. The language didn’t protect you; it was entirely the programmer’s job to check before using it.

C++ inherited NULL, but because NULL was really just 0, things could get messy. The compiler sometimes couldn’t tell whether you meant the integer 0 or a null pointer. To fix this, C++ 11 introduced nullptr, a dedicated keyword of its own type (std::nullptr_t). It removed the ambiguity and made code clearer:

Foo(nullptr);

Now the compiler knew you definitely meant “no object,” not “zero.”

Visual Basic went its own way with the keyword Nothing. At first glance, it worked like null:

Dim text As String = Nothing

But there was a twist. In VB, Nothing really means “the default value of this type.” For reference types that default is Nothing (null), but for value types it’s something else: 0 for integers, False for booleans, and so on.

Dim count As Integer = Nothing   ' actually 0

This could trip up developers moving between VB and C#, because in C# value types don’t silently “fall back” to null or zero — unless you explicitly make them nullable.

Each of these choices — NULL, nullptr, and Nothing — shaped the expectations developers brought with them into C#. And while C# inherited the same underlying problem, it also started to evolve solutions of its own. That’s where we’ll go next.

That’s all for now—may your code find clarity, and your thoughts unravel the roots of ‘nothing.’ With a quiet pause on history’s page, I set down my pen.