[whycombagator]

> 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."

[jonathanoliver]

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.

[fendy3002]

It's usually the company policy that use TFS for C#, not developers. Usually it's the Microsoft marketing scheme to include .NET solutions with TFS.

[whycombagator]

> 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.