.NET Team member here. We don't look at these specific benchmarks. Our belief is that they are wild west w/limited moderation of what is reasonable/real-world and not. Not necessarily a reasonable comparison, but we focus on TechEmpower[1]. You can check out the latest .NET performance improvements in our latest blog post on the topic [2].
I am thoroughly impressed with you what your team has accomplished. Roughly 7-8 years ago, the company I work with switched away from .NET (to Go) largely because our performance with IIS for HTTP traffic running .NET was...poor by comparison to other available options. I wrote a blog post[1] on the subject.
It's been exciting to watch the hard work you and your team are investing to make .NET (Core/Framework/etc) faster. In fact, virtually every single issue or point I raised in my blog post has been addressed to my sanctification and then some. The Techempower benchmarks show the massive strides you've all made and now I'm delighted to see .NET consistently performing at or near the top of the benchmark even without heavy customization/modification. To this day, I still really love C# as a language and there are a number of significant things in C# that I wish the Go ecosystem would adopt. If/when bootstrap a technology stack again, you can bet that C#/.NET will be the top contender on the list of options.
Thanks again for all of your effort. It is very much appreciated and admired, even if I'm not using that tech stack at this point.
> Roughly 7-8 years ago, the company I work with switched away from .NET (to Go) largely because our performance with IIS for HTTP traffic running .NET was...poor by comparison to other available options. I wrote a blog post[1] on the subject.
After reading this quote, and as a former .NET developer, I was really interested in the performance issues/story your blog would go in depth about. Instead, I found it strange, as I skimmed your blog, that I didn't see any specific scenario or perf numbers/bottlenecks discussed (seeing as you specifically state your company moved away from .NET due to IIS perf issues) - it was very generalized/hand-wavey. Do you happen to remember anything specific? Or were the reasons your company moved away from .NET literally the contents of the blog post?
It seemed to me that your frustration was more surrounding the MS bloated tooling &/or windows.
Some quotes from your blog:
"Once I used TFS on a small job and it was a monster--just like everything else from Redmond. It infected my project files and contaminated my source directories. Yuck. No thank you. Give me command line git any day...or perhaps SourceTree if you need a little love from a GUI."
You could definitely have used git back then.
"As a .NET developer, when you start a new project there are a few things you'll typically do (by hand, of course):
- Create a new solution
- Add it to Team Foundation Server
- Create a corresponding website entry in IIS
- Create a new SQL Server database
- Associate the Entity Framework with the solution (typically for projects created after 2010)
Start designing your database and your ActiveRecord entities."
You absolutely did not have to use EF or TFS, even back in 2014.
The post ends with:
"And that's why I left the .NET Framework because it kept reasserting itself and wanting to be more than it was: an implementation detail."
In my blog post from 2014 I was mostly illustrating a typical workflow that I've seen over and over and over at numerous Microsoft shops in 2000s all the way through 2014. I was always interested in messaging queuing systems and NoSQL and memcached but when I'd interact with devs from various organizations the answer was "We use SQL Server." I was intrigued because the use cases they were bending SQL Server to handle were more akin to map reduce kinds of scenarios. In other words, the mantra of 10+ years ago was "stay fully in the Microsoft ecosystem, it'll solve all your problems."
Also at that point as we started to use EC2 heavily and the workflow was so straightforward for Linux. The AWS docs would always have caveats for Windows, e.g. "This is how it works...but in Windows you also have to do X and you can't do Y." So that's why we jumped ship.
As mentioned in my earlier comment, I think they've completely tackled all of the perceived shortcomings to the point where the .NET stack is highly attractive and very competitive compared to other stacks.
> It's usually the company policy that use TFS for C#, not developers.
I agree, but remember we are specifically talking about a company that switched it's whole business off .NET. A company that makes such a decision is probably one that could also make the call to switch version control systems without changing stacks.
It's been exciting to watch the hard work you and your team are investing to make .NET (Core/Framework/etc) faster. In fact, virtually every single issue or point I raised in my blog post has been addressed to my sanctification and then some. The Techempower benchmarks show the massive strides you've all made and now I'm delighted to see .NET consistently performing at or near the top of the benchmark even without heavy customization/modification. To this day, I still really love C# as a language and there are a number of significant things in C# that I wish the Go ecosystem would adopt. If/when bootstrap a technology stack again, you can bet that C#/.NET will be the top contender on the list of options.
Thanks again for all of your effort. It is very much appreciated and admired, even if I'm not using that tech stack at this point.
[1] https://blog.jonathanoliver.com/why-i-left-dot-net/