Another day, another clickbait article about why C# is sick. Or dying. Or already dead (you just don’t know it yet). As a person who’s written a lot about dead and dying Microsoft technologies (see my pieces on Silverlight, Access, VB, Expression Studio, and ASP.NET Web Forms), I’ll be the first gravedigger when the time comes to put C# in the ground. But in the meanwhile, my focus is on a different question — what’s behind this sudden explosion of wrong-headed hot takes?

We could talk about the desperate lengths people go to to get a few picoseconds of attention in today’s hyped-up social media world. But I prefer to respond to the underlying anxiety that leads otherwise sensible developers to panic about one of the world’s top 5 programming languages.

Of course it’s true — C# won’t live forever. The best authority on that question is Microsoft program manager and keeper of the C# language specification Mads Torgersen. In a perceptive interview a few years ago, Mads was asked about feature sprawl and C#’s future:

“Most programming languages have a life expectancy. One common tipping point is where the language becomes too complex with too many features. Could you imagine this happening with C# … Are we approaching the tipping point?” — Suprotim Agarwal

We’ll get to his answer at the end of this article.

Just kidding. Here’s how he summed up the health of the C# ecosystem:

“I can certainly imagine that happening with C#, but I am not sure we are anywhere close. People have said that about C++ for ages, and yet it keeps doing just fine. Our complexity budget is considerably smaller, but I do not see signs of the community starting to fracture over complexity of the language.” — Mads Torgersen

And that’s a reasonable way to describe C# today. If you’re in a hurry, you can be satisfied, close this browser tab, and move on to your real development work. But if you have a moment, let’s reflect on the evolution of C#.

The birth of C#

I’ve been programming in C# since the earliest beta versions of the language in 2000. Originally, it was designed as a Java-killer called Cool (for “C-like Object Oriented Language”) and Microsoft seriously considered keeping that as the official moniker. But Cool is an objectively terrible name, with a “failed browser plugin from the 1990s” feel. Thankfully, Microsoft backed away due to copyright issues.

I loved C# then, and I still love it today. But every once in a while I stop and wonder — how is that even possible? Because the C# of today is dramatically different from the tidy, compact language that appeared two decades ago in .NET 1. Back then, having events as a first-level language feature was a luxury (and a late addition), because Java didn’t have them. Today, we can tie ourselves up with built-in keywords for asynchronous programming (thanks, async and await), LINQ query expressions, and functional programming concepts that are all included as first-level language features. Developers aren’t lying when they say this isn’t the same C# they learned on.

The meaning of multiparadigm

The change that causes the most pain is C#’s drift toward functional programming. Functional programming is already a challenge for developers that grew up on object-oriented concepts. Now add the way C#’s functional programming concepts overlap its existing OOP ideas, and you can see why there’s confusion. You may have become comfortable with classes and structs, but now you need to understand the subtly different semantics of records. You remember switch as a creaky branching statement for conditional logic, but now you need to understand how it’s been repurposed for functional pattern matching. You knew cloning, but now we’ve got the with keyword. And so on. Long-time C# developers who stumble across these new features can be excused for asking “what happened to my language?”

But this is the curse and blessing of a multiparadigm language. C#’s philosophy is to be agnostic as possible about programming style. You can pick up C# and use it to write functional code or OOP code — we won’t judge. This flexibility means there’s more to learn than in a strictly prescriptive language. But it also means that C# can adapt, chameleon-like, to new software design trends and requirements.

Mads Torgersen has often remarked that if he were redesigning C# from scratch, the language would skew toward a more equitable balance of OOP and functional. Critics might say that C# doesn’t do enough with functional programming to make the new complexity worthwhile. Personally, I’m a “more is more” person (except when we’re talking autogenerated code and ORMs). I find C#’s ever-expanding functional capabilities very exciting.

The growth of modern codebases

If I’m being honest, I miss C# 1.0. I loved the way it fit into Eric Gunnerson’s early C# tutorial, a short and snappy book that unfolded a complete concept in each compact chapter. All you needed was a day or two to master the language basics before you were ready to start in on the real work of learning the .NET Framework.

But the evolution of C# also parallels the evolution of modern codebases. Today, C# is used in projects than are dramatically larger than before. Many of C#’s new features offer conveniences that can save valuable time and — more importantly — prevent minor but common mistakes from slipping, undetected, into your next Git commit.

Consider this type of code, for example, which I spent years of my life writing:

private int _totalIterations;
public int TotalIterations
{
    get { return _totalIterations;}
    set { _totalIterations = _totalIterations;}
}

Except there’s a mistake here. The property setter won’t ever set _totalIterations because it doesn’t use the value keyword. This fact is obvious to any C# developer who’s worked with the language for longer than a few hours, but studies consistently find that this is exactly the type of brainless error that we programmers keep making. C#’s autoimplemented properties feature makes the code easier to read and less vulnerable to typos and mistakes:

public int TotalIterations { get; set; } 

It’s a little thing, but little things matter. (Made up statistic: Productivity is 95% little things.)

C# has done plenty of work like this to make it easier to write clean code. We’ve got top-level statements (no main() method required), implicit usings (no more clutter of namespace imports), and file-scoped namespaces (less horizontal whitespace and side-to-side scrolling). So credit where credit is due. Even as the complexity of C# continues to grow, the C# team keeps giving us features to help tame some of the chaos.

“There’s no question that the C# of 15 years ago was easier to learn. There’s also no question that today’s C# is much more useful and productive in today’s landscape.” — Mads Torgersen

New complexity beats legacy status

Language design is a necessary compromise. The C# designers operate under unavoidable constraints — most importantly, C# features can be added but never removed or even modified. If C# were written today, delegates would probably look a little different. But ensuring iron-clad backward compatibility is the first commandment of C# evolution.

No language gets to be rebuilt, revised, or cleaned up once it’s widely released. You may think that today’s C# has too much magic, too much upward drift, too much psychic weight. But consider the alternative. Unlike Microsoft’s legacy language VB, we get a new version of C# with measurable improvements every year. C# 10 was released last November, and C# 11 is set to appear like clockwork in November 2022. And at this very moment, there’s a team of brilliant programmers trying to make your favorite language better. No matter how you feel about tackling new concepts and facing new challenges, constant change is one of the reasons to be most excited about C#.

If you believe C# has a thriving future, check out the features that are coming in C# 11. Or visit my tech graveyard to see the technologies that didn’t make it. To keep in touch, subscribe here for the Young Coder newsletter.