5 ms·

The reason why it's a myth worth dispelling now is that The (legacy) .NET Framework, which used to be ".NET" back in the day, actually was hilariously slow for

The reason why it's a myth worth dispelling now is that The (legacy) .NET Framework, which used to be ".NET" back in the day, actually was hilariously slow for any kind of web or networking work. It had decent CPU crunching power, but also only on Windows machines. Comparisons of benchmarks with C# vs. Rust or whatever are unproductive and it's a shame that the article focuses on that. The reality is that you can write C# or F# code today, focus on solving your problem instead of performance, and have it handle a production workload admirably well. That used to not be true circa ~2010. Thankfully it is true now :)

bastardoperator 5y ago
This is my experience with dotnet. Considerable amount of legacy code coupled with different web frameworks along the way. While the app was slow, I found the amount of time it took to make changes to be the unbearable part, mostly a whack a mole situation. Maybe I worked with some bad developers, but they all acted as if dotnet was the best thing ever with constant mentions of dependency injection and blaming the GAC for problems they clearly created..
- nightski 5y ago
  All ecosystems have churn. While .NET has had a fair share of churn, to me it seems in line with any other platform that has not only survived but thrived for this long.
- gregmac 5y ago
  Most of the problems I've seen of this sort are from easy-to-make design issues, like constantly reassigning a string value to modify it (lots of allocations, with lots of GC), or using an IEnumerable with .count() then iterating with foreach (causes multiple enumerations and maybe loads), or unnecessary conversions between List and arrays. If you don't understand what's happening underneath, these mistakes are easy to make. The worst part is these compound over time, and also aren't obvious at small scale. This isn't a problem unique to .net though.
hughrr 5y ago
I disagree. It was pretty good even back in 2005. There were a couple of very large high traffic sites I ran on it back then. I wouldn’t use it now because the big cost is always humans in a project and anything .Net turns into a damage amplifier because of the amount of fettling and dealing with churn you have to do to get anything done. Even with .net 6.
- tomnipotent 5y ago
  Agreed. I had a web app in 2006 handling 20k RPS on three dual core/2GB servers without breaking a sweat. This included per-server connection pooling to MSSQL and lots of UDP traffic on top of memcached. It was rock solid.
TideAd 5y ago
The .NET Framework HttpClient was considered really slow by the .NET team themselves. In .NET Core they scrapped the old code entirely so they could build a good one.
branko_d 5y ago
StackOverflow was founded in 2008 and probably had plenty of "production load" circa 2010.
- phillipcarter 5y ago
  StackOverflow is also a classic example of an engineering system that has focused on performance since the very beginning.
mark-r 5y ago
I believe StackOverflow has been running with .NET since they started in 2008, and they were pretty surprised by the scalability and performance. They do use Windows servers though. They've been reasonably open about sharing their architecture.

bastardoperator 5y ago

This is my experience with dotnet. Considerable amount of legacy code coupled with different web frameworks along the way. While the app was slow, I found the amount of time it took to make changes to be the unbearable part, mostly a whack a mole situation. Maybe I worked with some bad developers, but they all acted as if dotnet was the best thing ever with constant mentions of dependency injection and blaming the GAC for problems they clearly created..

nightski 5y ago
All ecosystems have churn. While .NET has had a fair share of churn, to me it seems in line with any other platform that has not only survived but thrived for this long.
gregmac 5y ago
Most of the problems I've seen of this sort are from easy-to-make design issues, like constantly reassigning a string value to modify it (lots of allocations, with lots of GC), or using an IEnumerable with .count() then iterating with foreach (causes multiple enumerations and maybe loads), or unnecessary conversions between List and arrays. If you don't understand what's happening underneath, these mistakes are easy to make. The worst part is these compound over time, and also aren't obvious at small scale. This isn't a problem unique to .net though.

hughrr 5y ago

I disagree. It was pretty good even back in 2005. There were a couple of very large high traffic sites I ran on it back then. I wouldn’t use it now because the big cost is always humans in a project and anything .Net turns into a damage amplifier because of the amount of fettling and dealing with churn you have to do to get anything done. Even with .net 6.

tomnipotent 5y ago
Agreed. I had a web app in 2006 handling 20k RPS on three dual core/2GB servers without breaking a sweat. This included per-server connection pooling to MSSQL and lots of UDP traffic on top of memcached. It was rock solid.

TideAd 5y ago

The .NET Framework HttpClient was considered really slow by the .NET team themselves. In .NET Core they scrapped the old code entirely so they could build a good one.

branko_d 5y ago

StackOverflow was founded in 2008 and probably had plenty of "production load" circa 2010.

phillipcarter 5y ago
StackOverflow is also a classic example of an engineering system that has focused on performance since the very beginning.

mark-r 5y ago

I believe StackOverflow has been running with .NET since they started in 2008, and they were pretty surprised by the scalability and performance. They do use Windows servers though. They've been reasonably open about sharing their architecture.