6 .NET Myths Dispelled — Celebrating 21 Years of .NET
According to Wikipedia, .NET will be celebrating it’s 21st birthday this year on February 14, 2022 (author’s note: the date was changed! It’s the 20th birthday of the official release!).
It’s been around for so long that I think many myths and misunderstandings about .NET from the early days persist; modern .NET is very different from the .NET Framework that started the whole journey.
In celebration of .NET reaching Minimum Legal Drinking Age here in the US, grab a cold one and let’s dispel 6 common myths about .NET!
- .NET is for Windows
- It’s slower than Node/Python/Go/Rust
- It’s a legacy platform
- The tooling is expensive
- .NET isn’t open source friendly
- It’s for boomer enterprise development
Myth 1: .NET is for Windows
This myth persists from the early days of the .NET Framework. Indeed, it was true: the .NET Framework was initially built for Windows and in its internals, had many references to the Win32 APIs via P/Invoke which barred it from being cross platform and this persisted even while the Mono project was started by Miguel de Icaza to bring .NET to Linux.
It wasn’t until Microsoft got serious with .NET Core in 2016 did they start to address many of the gaps in Mono and the lingering dependencies on the Win32 APIs. Those early days of .NET Core vs .NET Framework vs .NET standard were a mess, but thankfully, that’s all in the past with .NET 5 and now .NET 6.
Today, .NET 6 — the most current .NET — runs on Windows, Linux, and macOS with support for x86, x64, Arm32, and Arm64.
This means that, yes, you can build .NET applications on the latest M1 MacBooks:
And run them on the latest AWS Arm-based EC2 instances. Microsoft’s official Docker images includes builds for all major Linux platforms:
This also means that you can build .NET in your CI/CD pipelines on Linux whether you’re using GitHub, GitLab, or other CI/CD tools.
Myth 2: It’s Slower than Node/Python/Go/Rust
In reality, .NET 6 is extremely high throughput and in web workloads provides many times the throughput of any of the frameworks running on Node and Python while competing favorably with Rust and Go.
Where this myth may have started is with earlier versions of ASP.NET. You see, ASP.NET and .NET have always supported asynchronous programming models (what we know today as async/await), but it was somewhat awkward to use and inaccessible to developers in the earlier days (using asynchronous delegates) and thus rarely (and I mean very, very rarely) ever used by most developers. Without asynchronous programming, blocking I/O becomes a key constraint, even in a multi-threaded runtime.
In recent years, the .NET team has also focused heavily on core performance in almost every aspect of the run time and addressed many inefficiencies in the code, often re-writing the internals along the way! While obviously it is not going to beat Rust or C++ in raw performance, it isn’t far behind in workloads like running a web application or web API. Facilities such as the Task Parallel Library and Span provide a higher ceiling for building for throughput and performance.
In the open source TechEmpower Benchmarks, Round 15 from February 14, 2018, you can see that ASP.NET actually trails Node.js:
But by Round 20 in February 8, 2021 — just 3 years later — it is absolutely crushing Node (teal-green) and Python (blue) and just behind Rust based servers:
What seems insane is that .NET scores 3x higher on JSON handling than Node and scores an order of magnitude higher in plaintext handling. Just what are these benchmarks? Are they somehow biased towards .NET? Here’s the code for Express:
And here’s the code for .NET 6 (to be benchmarked in round 21):
If we look at the chart above, there is an order of magnitude in scale between Express and .NET in these two actions (JSON: 105,747 vs 1,242,834 and text: 140,585 vs 7,022,212) and I expect the raw numbers to widen with .NET 6 in round 21.
The TechEmpower benchmarks aren’t just string handling of course; it also includes scenarios that mimic real-world applications and tests different database backends, different ORMs, different request types (read only vs read-update-write), as well as different levels of concurrency and .NET shows very competitive performance at the top of the list across the 1-Query, 20-Query, Fortunes, and Updates test scenarios.
Don’t be fooled by the visual position in this chart; I’ve filtered to only JavaScript, Python, Rust, and Go runtimes. Overall, Node is in 56th position while Express is all the ways down at the bottom in 94th with no Python based framework higher than 61st.
In gRPC benchmarks, .NET is also crushing it (an order of magnitude greater throughput than Node):
If I told you that there was a way to achieve multiples of your current application throughput using a well-supported, mainstream, mature, open source, mutli-platform runtime, and a language that looks an awful lot like TypeScript — on your current infrastructure or cloud budget — wouldn’t that be worthwhile to seriously consider? At scale, this delta in throughput can equate to a significant delta in cost.
It’s not just in web benchmarks. In fact, .NET even trounces Go in raw compute. (See Alex Yakunin’s series on Go vs C# for a much deeper dive.)
Of course, there are cases where .NET isn’t the right choice compared to Go, Python, and Node. This is especially true when it comes to “cold starts” because of the nature of the just-in-time compilation to machine code (plus other nuances of how .NET processes start) and thus making it unsuitable for certain types of applications such as CLI tools or serverless functions that require near instant response for a single request. Many of Microsoft’s own CLI apps, for example, are written in Python for this very reason!
However, it’s not nearly as bad as it once was. Tai Nguyen Bui has a great set of benchmarks that show how .NET cold starts can be reduced in AWS Lambda with very little effort and the Microsoft team is working on an improved native ahead-of-time compilation (“native AOT”) for .NET 7.
With additional improvements and a focus on performance with each release, I have no doubt that .NET will continue to get faster.
Myth 3: It’s a Legacy Platform
To be fair, .NET would now be considered an adult here in the US so it’s easy to see it as a “legacy” platform with the new cool kids being Go and Rust.
Yet I find this assessment of the platform to be misaligned with reality. In 2010, .NET shipped with the Dynamic Language Runtime (DLR) and in doing so, ushered in an era of rapid and continued innovation with respect to the runtime and supported programming languages as it allowed dynamic languages and dynamic language features to be incorporated on top of .NET. Here’s a blog post I wrote in 2009 showing how to implement the Visitor pattern using double dispatch in C# 4.0.
As .NET has evolved, it has also adopted many functional programming techniques. Today, it is possible to build using a mixture of object-oriented and functional techniques in .NET. The runtime supports:
It has lambda closures, generics (which Go is just getting around to), extension methods, anonymous types, record types, local functions, channels, and more!
According to GitHub’s 2021 State of the Octoverse report, C# has had a bit of a resurgence in the last few years:
There’s good reason for more developers to consider C# on the server, especially those that are already comfortable with JavaScript and TypeScript.
With LINQ, C# looks an awful lot like JavaScript:
It should be no surprise that C# and TypeScript bear a striking resemblance because they were both designed by Anders Hejlsberg of Microsoft:
TypeScript:
C#:
(If you like Nest.js, chances are you’ll probably like .NET Web APIs because of how congruent the two frameworks are.)
Check out this small repo which highlights some of the congruencies between JavaScript, TypeScript, and C#:
C# — the most dominant language on .NET — continues to evolve and add features. And as Microsoft continues to invest in F#, C# will inherit many of the dynamic, functional elements of F#.
Myth 4: The Tooling is Expensive
Like many myths about .NET, this likely formed based on early tooling in Visual Studio which was indeed, quite expensive (in the thousands of dollars!).
These days, not only does Microsoft provide a free, pretty much fully featured Community Edition of Visual Studio, there are other options to choose from as well:
These days, I do most of my C#/.NET in VS Code on a 2021 MacBook Pro M1:
And it works (mostly) flawlessly.
Even fully featured Enterprise Visual Studio is reasonably priced nowadays for the productivity that it provides.
Myth 5: .NET Isn’t Open Source Friendly
Like many .NET myths, this one originates from the days of Microsoft under Steve Ballmer.
Since Satya Nadella has taken the reigns, Microsoft’s entire trajectory with respect to open source has shifted. By no means is Microsoft’s OSS approach perfect and there’s still a quite ways for Microsoft to transform and grow on this front, but it has also been a long journey from the closed ecosystem it was in the early days.
.NET itself is governed by the .NET Foundation, the .NET compiler along with many other internals are all in GitHub public repos, and since 2015, it has been certified for Red Hat Enterprise Linux.
While the usual suspects dominate GitHub’s language charts, C# pulls in at a respectable 9th place.
While the Nuget package repository doesn’t have nearly as many package options as NPM, I find that the key packages that matter are all very stable, well written, secure, and well documented; I’ve rarely felt lacking in open source options for the applications I’ve built.
What’s more is that Nuget tends to have less “filler”. This is a side effect of a much richer set of standard and base class libraries for .NET. Having a deep set of first party libraries written and maintained by paid professionals is an incredible asset.
Myth 6: It’s for Boomer Enterprise Development
(via u/similarintrests)
Yes; it is a great platform for enterprise development used in banks, finance, insurance, defense, enterprise content management, and cloud-scale backends. This is a Good Thing™ in my book as it means that you get all of the security and performance benefits of a platform that’s deployed to support mission critical workloads.
But .NET is also one of the most versatile platforms to build on, full stop.
Very few languages are as accessible as C# while being able to build applications for virtually any use case from desktop to devices to web servers to 3D games. The Unity game engine natively supports C# and a ton of games are built on Unity including Cuphead, Hearthstone, Rust, and Escape from Tarkov!
.NET can also be used to build cross-platform apps using a number of frameworks like:
With .NET 6 minimal APIs, Microsoft moves .NET closer to the realm of traditionally more accessible languages and runtimes such as Go, Python, and Node.js and makes it far more approachable for hobbyists and weekend hackers.
Here’s a .NET 6 minimal Web API:
Compare that to Express (JavaScript):
Or Fiber (Go):
Or Flask (Python):
My hope is that as .NET turns 21, this post helps dispel a few of the long-standing myths about .NET which continue to be prevalent in the development community.
The reality is that .NET and C# are an extremely versatile and highly performant runtime and language to work with while providing many additional benefits for developers, teams, and enterprises; the platform and language continue to evolve and innovate.
If I’ve piqued your interest, check out this repo that shows how to build a modern React + Mongo web app with a .NET 6 Web API and see for yourself:
Especially for teams considering TypeScript on Node.js web frameworks like Express or Nest, .NET and C# should definitely be evaluated given the tremendous advantage in productivity and throughput that can be achieved!🍻
(For more discussion, check out this Reddit post and this Hacker News thread)
