Microsoft have just posted the first of what will be a series of posts on the design tenants and goals of .NET. This first post acts as an introduction, but it's also very detailed, and moderately technical. It's 5000 words long, so brace yourself.
In this post I provide some general thoughts about their post, highlight some of the points it raises, and discuss the target audience.
This is a short diversion from the deep dive into minimal APIs. That series will continue again next week!
Don't worry if you haven't read their post yet, I'll give you the gist of it here. If you've already read it and formed your own opinions, I'd be interested to hear about them in the comments (whether they're the same or different from mine)!
Who is this post for?
One of the main questions that kept going through my mind reading the post initially was "who is this for?" The post highlights both highly-technical "advanced" features like ref structs and stack-allocated memory, but also a lot of "basic" features like Exception handling and lambdas. So who is meant to be reading it?
My first thoughts were "this is too technical for newcomers to programming" but also not detailed enough for people who already know C#. So who is it written for?
My initial focus on newcomers was likely influenced by the discussion between Jeff Fritz and Nick Chapsas on the Keep Coding Podcast](https://www.youtube.com/channel/UCTWyucdJaJNxJn5BGWRa_kg). Definitely worth listening to and subscribing, Nick has some great conversations on there.
But this post (and presumably the remainder of the series) makes sense when you consider it in the context of the wider industry. The twitterverse/blogosphere/mastadonoverse(?) is always filled with "why we moved from Go to Rust", "why I switched from Rust to Go", or "what is Deno and why you should try it". Where is .NET in all of this?
Part of the problem is that "modern" .NET (née .NET Core) is still tarnished in the larger industry by its .NET Framework heritage. So many people still think that .NET is the slow, monolithic, Windows-only framework of 10 years ago. Things are different now.
So the target audience is technical people. It's technical people who are currently using other languages and technologies. It's the people who are evaluating other languages when their current ecosystem isn't cutting it. And it's for people who are interested in .NET but need some ammunition to point their colleagues to, when their colleagues only know about the "old" .NET. In fairness, they call that out at the start of the post:
It describes “what you get” at a foundational level when you choose .NET and is intended to be a sufficient and facts-focused framing that you can use to describe the platform to others.
So with that in mind, lets look a little at the content of the post.
What is a "Design Point"?
The intro to the post says (emphasis mine):
This first post in the series provides a breadth overview of the pillars and the design-point of the platform
OK, good, but what's a design point?
It's not a phrase I've heard in connection with software before…It rang a bell from my uni days related to systems engineering, which seems to correlate with most of the references I could find online. The design point in turbojet design defines a specific set of parameters such as the flow rate and thrust that the engine is designed around. The actual operation of the jet may veer away from this point, but it sets the focus for everything about the engine.
In a similar way, the post describes the .NET "design point" as Productivity, Performance, Security, and Reliability. It's perhaps stretching the design point metaphor a little, but nevertheless, these are the guiding principles around which the language is defined. They're it's North Star. The key tenants. However you want to describe it!
For anyone up to date with the .NET ecosystem, those probably won't be surprising, but that's not necessarily the case for folks outside the ecosystem. As far as I know .NET has always had a reputation for Security and Reliability, and I'd be willing to believe that's well known across the industry. But Performance and (for some implications) Productivity? That's pretty new, and not so well known.
Surprising features of .NET, if you're out of the loop
Ever since Microsoft shifted to .NET Core, performance really became a focus. They started publishing benchmark results on the independent TechEmpower platform, and actually trying to improve on those results. Every release they document performance improvements in both the libraries and in the ASP.NET Core framework. And .NET really is fast now.
It's regularly among the fastest frameworks benchmarked, and there's always efforts to improve. Of course, the numbers above are for micro-benchmarks and Microsoft was (rightly IMO) criticised for being overly simplistic with these numbers. Nevertheless, these improvements translate to real world performance improvements, as Microsoft have shown by upgrading their own Azure apps (from the .NET Conf 2022 keynote):
Productivity is another feature that will likely take outsiders by surprise, depending on how they're thinking about productivity. Microsoft has been well known for providing drag-and-drop solutions like VB, WinForms and even WebForms, but that's not what most technical people are thinking about when they're thinking about a "productive" language.
For most people, productive means I can get something running quickly. It means a simple tech stack I can install and run on any OS. It means not needing 300 lines of code to write a simple API.
In the "bad old days", .NET Framework fell down on basically all those points. You had to be using Windows. You had to download endless GBs of Visual Studio before you could get started. You had to add multiple configuration files, configuration classes, controllers, etc.
With .NET 7, all of that has changed.
You can develop and run on macOs, Linux, Windows. You can build from the command line with Vim and VS Code, or with full IDEs like Visual Studio and JetBrains Rider. You can create three line hello world APIs:
var app = WebApplication.Create();
app.MapGet("/", (string? name) => "Hello {name ?? "World"}!");
app.Run();
That's productive. And this still feels like one of the biggest misconceptions about .NET in the wider ecosystem.
Another feature that may take people by surprise is Microsoft's support for industry standards. Obviously Microsoft has a somewhat sordid history of ignoring nascent standards and forcing their own approach. Some veterans will never forgive them for that (*cough* IE6), but things are very different in .NET.
As the post points out, .NET has been quick to adopt standards like gRPC and OpenTelemetry, even shipping support for proposed standards before they're stable, such as the HTTP/3 support in .NET 7. Being on the cutting edge like that is not something you could ever expect in the old .NET Framework days, but it's standard now. And honestly, it's refreshing😌
Will it change people's minds?
As well as hitting these high-level topics, the post gives an overview of (practically) every feature in C# and .NET: from foreach loops to LINQ and lambdas to generics.
The focus is, unsurprisingly, heavily focused on C# as the "main" language of .NET. It does point out that multiple languages can run on the CLR, but it's a passing comment…I suspect there will be some F# folks feeling snubbed again. But given the purpose of the post, it seems a reasonable enough approach.
The question is: is there enough here to entice people into .NET? They certainly hit a lot of major features:
- Type system—Generics, value vs. reference types,
refstructs, stack allocation. - Automatic memory management—Lots of details about the GC.
- Safety—Type safety, memory safety, thread safety.
- Error handling—exception handling.
- Concurrency—
Thread,ThreadPool,Task,async/`await. - Reflection—Late binding and plugin architectures
- Compiled binary format—Assembly layout and design.
- Code generation—AOT vs. JIT, hardware intrinsics
- Interop—Function pointers, C++ interop, source generators
- Binary distributions—Linux distributions, Web Assembly, source building
Wow, that's…a lot to take in. The selected topics feel a bit like, well everything. It's pretty overwhelming, even for someone who knows .NET well!
On the other hand, the topics also subtly go after certain sore points of other languages.
- Been using Go and running into issues with the GC? No need to throw the baby out with the bath water and go to C++ or Rust; check out .NET's tuneable GC instead!
- Fed up with
err != nilin Go; look at our shinyExceptionhandling 😉 - Want to have easy native interop; no need to fight with Rust's borrow checker, use .NET!
As an aside, I was interested to see the mention of a Virtual Mono Repo which consolidates all the different Git repositories into a single repo. It's primarily to satisfy Linux distribution requirements, but it also seems like it might be useful outside of that to have all the code in one place too.
Ok, but will this convince anyone to use .NET instead of something else? Maybe.
If someone is dismissing .NET out of hand, this post likely won't do anything to change their mind. It doesn't have the clickbait title which (while cringe) would increase views. It's not full of graphics and hooks that immediately pull you in. It's a detailed, somewhat dry, exposition of .NET's capabilities. You're probably not going to get past the first couple of sections at best, unless you're already invested in .NET to some degree, even if that's just a passing interest.
However, I can see this sort of post being very useful if someone is already interested in or considering using .NET.
- Maybe they haven't used .NET, and have always previously dismissed it, but they've vaguely heard that .NET is different now, and they're wondering how.
- Maybe they used .NET 15 years ago, but they've been out of the loop and want to see how things have changed.
- Maybe they already know .NET, and are trying to convince their peers that it's a good candidate and suitable for their team's needs.
In these cases, a reasoned, engineering-heavy post may well be more effective than a more pithy, flashy, post which could otherwise be dismissed as being overly "marketing" heavy. The marketing in this post is much more along the lines that engineers like (or think they like): a reasoned description of .NET's strengths.
From my point of view, I'm interested to see where the rest of the series goes. I'm not the primary audience, but there's enough titbits in there to keep me interested. Though a picture or two in a 5k word essay wouldn't go amiss 😶
Summary
The first post in Microsoft's ".NET Design Point" series provides a detailed overview of the .NET ecosystem, highlighting its key non-functional guiding principles: "Productivity, Performance, Security, and Reliability". The post goes in depth into many different aspects of .NET covering the type system, the GC, native interop, and distribution among other things. Each section provides a cliff-notes summary of .NET's best features, targeted at technical folk outside the .NET bubble. This is somewhat in contrast to other recent "outreach" efforts in .NET, which have been focused on making .NET attractive to beginners (a laudable goal).
Whether the post (and following series) will have the desired impact obviously remains to be seen, but it's nice to see this focus on user acquisition at the other end of the experience spectrum too.