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.
I work primarily in .NET and I completely agree with these sentiments. I couldn't have said it better but I'll add my $0.02 anyways.
.NET isn't necessarily slow* to work with (GSD, not benchmark wise), but it can be very restrictive and limiting to work with. This is probably great for "enterprise" (whatever that means anymore) where cutting edge technology is considered inherently risky, but in modern startup environments it's just not going to cut it. Community involvement and maturity is part of it too, a talent pool that has a lot more myopic developers who have limited themselves to one language, one framework and one stack is another. Windows as an environment is a third reason, it just doesn't have the same flexibility, tooling and automation of * nix environment. Fun, as a purely subjective reason, is a fourth, I just see * nix devs having more fun with the tools they are using and the stuff they are building.
*though in my own experience the incredibly strict static typing of C#/Java feels slow to me. If I'm trying to design my software well so that it is extensible, understandable and maintainable I find I have far less trouble with this in Ruby, even considering that I have far more skill and experience in C#. That's just my personal experience so YMMV obviously.
I recently hacked around a bug in a Python / API interaction by sending the request with Python system call to curl. I'm sure this was Not Right, but it did get'er done and on deadline. I suspect the API was somehow out of standard.
I figured out the problem 1) reading the Python code and 2) with what I'd learned about HTTP requests fooling around with curl scripts on the commandline.
No doubt a similar hack is available somehow in .NET / Windows. But I'm not sure that, outside a *nix environment, I'd have known about curl, or played with it enough to learn enough HTTP basics to figure out the problem in the first place.
> 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 solved what sounds to be a similar problem using reflection and the Linq ExpressionBuilder class(and related classes). It actually turned out really clean and powerful.
That's roughly what we did: the T4 template work in combination with a cache that a) takes LINQ expression trees with invalid, though ITable-compliant, classes; b) swaps out the ITable-compliant classes for LINQ to SQL's Table classes; c) compiles the expression tree into SQL; d) caches it, so we only have to pull this stunt once.
The power of Microsoft's tools is that this is possible. The bane of them is that it was necessary in the first place.
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.