So I don't really work at a start-up in a meaningful sense anymore (Fog Creek is a decade old), but my team is just a few people, and we develop in a start-up-like mode for Kiln, which is written almost entirely on a WISC stack.

I really, really like .NET, ASP.NET MVC, and C#. And I even have grown to appreciate IIS 7 and SQL Server. But if I left this company and did a start-up project all over again, there is no way in hell I'd pick .NET for the kinds of things I find interesting.

Here's the rub: whenever we're doing something in Kiln that Microsoft anticipated, the environment is among the best I could possibly imagine. There is something they already wrote that works, makes sense, runs quickly, and is flexible without taking you into IoC debugging hell. If you want to take on something that is not using cutting-edge web technologies (i.e., you're not using WebSockets, or working with big file uploads, or doing strange routing, or what have you), you're probably in great shape.

But when we do something that Microsoft did not anticipate, it's nothing but pain. Take allowing you to push Mercurial requests through HTTP: we still get into fights with IIS, two years down the line, because we keep encountering limits that Microsoft set that make absolutely no sense if you're not a vanilla CRUD app, and whose removal is poorly documented. For example, IIS limits the amount of headers you can have. This setting isn't actually even set in IIS proper; it's set in the generic HTTP layer of Windows, which can only be altered with a full-blown machine reboot. So when one of our customers dutifully managed to craft a Mercurial request that was over 8k or whatever the limit was, we had to go reboot every last fricking production web server during our peak load time so that they could actually get their changesets through.

Or take streaming requests: ASP.NET is so insanely aggressive about not allowing you to stream in requests that we had to replace swaths the official framework with our home-grown solutions before ASP.NET finally relented and quit trying to suck multi-gigabyte requests into RAM.

Or take LINQ to SQL. LINQ to SQL is great. Usually. If you're using it exactly as they intended. When we wanted to make some of our models automatically supply some query parameters, though...well, let's just say there was a lot of T4 templating involved to get around sealed classes, and leave it there.

I think the successful start-ups are the ones that are most likely to be doing something "weird." And when you're doing something weird, I think that Microsoft is the wrong stack to use.

If you ask me, that's why start-ups tend not to use .NET.