On C# and .NET quick release cycle

I sat to jot down a quick introduction to my C# 13 What’s New and Interesting session at the upcoming .NET Conference Italia 2024 next week, and what I ended up with instead is a long rant or, should I dare, stream of consciousness that is certainly inappropriate for a five-minute introduction. I’ll have to cut most of it down, especially on the personal story part, but my site might be a good place to host it in all its completeness. I may reference this post at the start of the session on Monday for those few poor souls who might be interested.

Exactly one year ago, on December 4, 2023, to be precise, we were here, in this same room, at the same conference, presenting C# 12. Some of you in the audience were present back then. If so, please raise your hands. Twelve months later, here we are again, looking at a new version of C#. It’s the new normal; this has been happening, give or take, since the advent of .NET Core and C# 8 in 2019. Previously, C# had a new release every 2–3 years, so the release rate has doubled or even tripled recently. Is this good news? If you’ve followed forums or social media, you might have noticed some controversy about the topic. The main complaint is that the language is changing too quickly, “chasing trends,” with no valuable addition to its core.

Most of these complaints come from old-timers around my age (maybe even ten years younger because I’m seasoned) and have been in the .NET environment for many, perhaps too many years. There’s always a certain inertia, a form of resistance to change, especially when it’s rapid. But I’m seasoned enough to remember when complaints went in the opposite direction: back then, the .NET Framework (the historical, monolithic, Windows-only version) moved like a dinosaur while the world was racing ahead. New languages were blooming. Old competitors were evolving at double or triple the speed, constantly innovating, and—this is key—attracting hordes of developers. There was a critical moment when this attraction became so intense that more and more developers set aside .NET and C# to explore new directions. I know because I was one of them.

Around 2010–11, I was set to create a new, rather complex platform of REST services, and instead of reaching out for my usual .NET toolchain, I chose Python. That marked the beginning of an adventure that lasted years and included the unexpected release of some reasonably successful open-source Python projects. The reasons I decided to abandon .NET and C# were several—not least the frustration with the lack of transparency and a clear path for the .NET ecosystem, its languages, with oh-so-many frameworks enthusiastically presented and then abandoned, changes of direction, and above all, in my case, it all being closed source, which didn’t allow me to dig deeper and understand why certain things didn’t work as expected. I clearly remember when I was writing my first REST service in Python and realized that in this new ecosystem if I didn’t understand what was happening behind the scenes (in my case, with the Flask framework), I could quickly look at what was going on because the entire Flask source code, like Python’s for that matter, was available not only for consumption but it was also open to contribution. Coming from the enterprise closed-source world, it was an empowering sensation.

The discovery of Flask was an absolute revelation, not for its intrinsic features (which were great) but because it was just one of the many options. In Python space, there were dozens of web frameworks at varying stages of maturity. There was a choice and often many different approaches to solve the same problem. I could experiment freely and decide what was best for my use case. Not only was I facing a vast and diverse world, but I could also use the operating system I wanted. Linux was much less demanding, let alone less expensive, for deployment than Windows, and behold! I could use a Mac for development. Open-source, cross-platform, with a vast community not only adopting the language and the standard library but constantly forging new solutions, making them available to the same community, almost always for free. It was the way forward.

I envied that such a thing was unthinkable in my world. But unbeknownst to many, Microsoft was watching and taking notes. To the best of my knowledge, it was mainly the developers inside the corp —the dev team—who, glancing out of the ivory tower, began a campaign of internal lobbying, initially scattered and disorganized and later increasingly coordinated, which in turn led to endless meetings, discussions at coffee machines, and gradually, slowly and then more rapidly, to the advent of the .NET Core project. The metaphor of a snowball slowly rolling down a slope until it becomes an unstoppable avalanche perfectly applies here.

So, years after my departure (not an actual departure—I still worked in .NET for our legacy products), a new and unexpected .NET appeared on the scene. It was open-source, cross-platform, and open to external contributions. We could and perhaps should have a lengthy discussion on the openness to external contributions, but we can all agree that a revolution occurred and was historic in scale. At the same time, Microsoft opened up to other stacks, mainly because of Azure. I was shocked when I was proposed for a Microsoft MVP Award for my work on Python, not C#, at a time when Python had little to nothing to do with Microsoft. It made sense, as there was an urgent need to speak to developers outside its ecosystem—and perhaps even more so to those like me who had left: Hey, look, we’re back, we’re on track, and we’re not evil anymore.¹ 

And there I was, finding my old stack (which I secretly, I admit, considered only museum-worthy) back to relevance, competing on equal footing with the rest of the scene. The delay was costly, though. Even today, I meet colleagues who think modern .NET is just a new version, if not a simple rebranding of the Windows framework of old, and C# is more or less the same, way behind the new kids on the block. It’s a shame, and there are responsibilities. Some choices could have been bolder and more disruptive, starting with naming the new framework—but that’s another story.

Today, I create REST services with Minimal APIs on my Mac and deploy them on Linux via Docker at zero or near-zero cost, just as I would with Python, JavaScript, Rust, Go, or any other stack. The performance is far better than Python’s (C# REST services make circles around Python’s), and the toolchain is rich and powerful, especially around the command line, while many think .NET is still a GUI/Windows thing. Quick release cycles are essential to compensate for lost time (and there was lots of it) and stay on the cutting edge, sending a continuous signal that the platform is alive, thriving, and constantly expanding.

Aldus Manutius, the renowned Venetian printer and publisher of the Renaissance, adopted the Latin motto Festina lente, which translates to Make haste slowly or Hasten slowly. This paradoxical phrase encapsulates achieving careful, deliberate progress quickly and precisely, balancing urgency with caution. I feel that, consciously or not, the .NET team is on track with Manuzio’s goal: they iterate rapidly to achieve progress, balancing urgency with caution.

Nowadays, both .NET and C# focus on performance and while there’s room for growth, the current achievements are extraordinary. We’re competitive with most stacks, if not significantly ahead of them. Frequent, more minor C# releases allow for quick adjustments. Attentive developers adopt them continuously. Meanwhile, those who aren’t in a rush (probably most of Microsoft’s long-time customers, slow-moving conglomerates and the like) benefit from performance gains and technological advantages (multi-platform deployment!) at a low cost because, while the framework and language evolve, great effort is put into preserving backward compatibility. In most cases, migrating to .NET Core and newer versions of C# requires minimal effort.

C# 12 introduced two significant features: primary constructors and collection expressions, with the latter being predominant in terms of syntactic, semantic, and performance importance. They weren’t the only new features but certainly the key ones. C# 13 innovates further but subtly—there’s less syntax and more semantics, building on last year’s new features. The improvements may be less flashy but guide developers in the right direction, often ensuring better performance at zero cost, sometimes even without us having to do anything. As we shall see, it happens because in recent releases—let’s say the last two or three— features were introduced primarily to improve the framework, which is also written in C#. Our higher-level applications benefit from all of this. It is a pattern we’ll observe repeatedly throughout this presentation.