You almost always have to rewrite your whole system anyway to scale to millions of users. It doesn't matter whether it's PHP, Python, C++, or ASP.NET; it'll have to be rewritten.
The real problem is the flip-side of something that the OP mentioned as an advantage: ASP.NET coders tend to be cheaper, less experienced, and hence less likely to know about some critical detail that'll boost adoption, whether it's usability or latency or security. As someone relatively inexperienced himself, the OP can't know what those things are, but it's highly likely that one of them will bite him.
In other words, it's correlation, not causation. ASP.NET won't make your site suck. However, ASP.NET biases your talent pool towards developers who suck, and that will make your site suck.
I'm curious how you conclude that ASP.NET developers suck ... there's a lot of shit programmers in all languages out there, that's why everyone's looking hard to find the rockstars/ninjas/whatevers.
You're looking for developers who have faced the problems that a typical web startup is likely to have faced as it grows and gains users. It is naturally easier to find those developers if you write it in a language that those current hot web startups frequently use.
To me this sounds like my friends who didn't want to go to UT because it 'was too big'. The awesome thing about too big is that if you look hard enough you are almost assured of finding someone like you.
Yes there are crappy c# developers. I've also seen some bad ass c#.
Right, "biasing your talent pool" doesn't mean that everyone in that talent pool sucks. There are certainly some very talented C#/.NET devs.
The problem is that when you go to hire, you have very little information about just how badass a prospective dev is, unless you've worked with them before. So if you take a random dev out of the C# pool, chances are he'll be worse than a random dev in the Python pool.
So if you take a random dev out of the C# pool, chances are he'll be worse than a random dev in the Python pool.
That was probably true in 1995. But not today. Python has become the new Pascal/Java. Commonly the intro language in CS, so you have a lot of students who graduate using Python regardless of skill.
If you said Haskell, then probably. Actually C++ maybe more then either, surprisingly.
Only if you assume that hits are evenly distributed throughout the day and throughout the month. Very few sites have that sort of traffic pattern. 30 million hits/month quite likely means peaks of 100 QPS followed by periods of 1 QPS.
My beef with ASP.NET is that it makes it disturbingly easy to write code that doesn't scale well and then is ridiculously hard to scale after the fact.
It really is all about the initial design not the language. ASP.NET just makes it too easy to go with bad design and library choices, not to mention the tons of examples of bad design that newbies might accidentally follow at the beginning.
Of course, you don't have to use the magic of WebForms (as I'm sure you know). You can use it just like 'MVC' where the code-behind class definition is the controller. In fact, now that I think about it, the big difference is that the controller-view mapping is static in WebForms (with code-behind) and dynamic in MVC (method loads a view).
Isn't this true of any language? ActiveRecord associations in Ruby on Rails are brilliant for getting code out the door, but the queries it produces along with complex lazy loading can make a database melt.
My beef with ASP.NET is that it makes it disturbingly easy to write code that doesn't scale well and then is ridiculously hard to scale after the fact.
Explain? Example? I don't see how this could possibly be true for .net but not for Rails or Python or PHP or whatever.
I think what noonespecial is probably getting at is that because .Net is usually written in Visual Studio a lot of people stick applications together in a RAD approach without giving much consideration for what is happening under the hood. Not all, of course, but probably a larger proportion that for platforms that don't have tools with RAD features like Visual Studio.
WebForms in ASP.Net are pretty much an attempt to take the developer experience of Visual Basic and make it work on the web - arguably with mixed results.
I really don't think there is anything wrong with .Net as a platform - but things like WebForms can be rather disturbing if not used with care.
Thanks -- it's such a good talk.
The final Q&A section of the talk is the best Q&A I ever saw.
Aside of tons of insights Joel was gently picking up on Googlers (e.g. by doing search using Bing).
You're right, .NET (even though I despise it) scales as well as anything else. Scalability is much more about design decisions than language/platform choice.
However, Joel Spolsky is a tool. Everyone I know and respect thinks he's a tool. He is a prime example of being successful because of being lucky, rather than being good. Do not quote Joel, he can't form a valid argument for a topic without circling back on himself to save his life.
Actually, that article is one of the most interesting and useful examples to point to when discussing the insanity that is Joel. That solution is just so ridiculous.
His software runs on a compiler that has had 2 months work put into it and worse, it compiles to either VBScript or PHP.
It's probably the most counter-intuitive solution ever implemented to solve the problem of needing a web-based application to run on both Windows and Linux.
Except when it came time to move to .NET/Mono, they only had to update their compiler to generate IL instead of rewriting the whole app from scratch. Sounds smart to me.
Except they are still stuck with any badly implemented language "features" in their own language that they only spent 2 months on. Language design and implementation is hard, just ask the dozens/hundreds of full time developers that work on ruby, java, php or .net itself.
Do you have inside knowledge of their framework? Did you know wasabi has memoization and heap of other things frameworks like .NET don't even have? They spent a lot more than 2 months on Wasabi. I think your information is outdated.
Whether Joel Spolsky is or is not a tool, lucky, good etc is completely irrelevant. He and the rest of the SE/SO team has built a highly scalable solution based on .NET. So in a discussion about scaling on .NET, it absolutely makes sense to listen to his experiences.
Actually, FogBugz is trivial to scale - there is never any more than a few dozen, to hundreds of users for any one project.
And Copilot wasn't even envisaged or created by Joel, but was rather a project created by some interns.
FogCreek doesn't innovate (they have a bug tracker and a remote support application based on VNC). Joel just happened to be one of the first to blog constantly about technology. He doesn't even allow comments on his posts because he doesn't want to have to deal with people contradicting him (not that he doesn't do an excellent job at this himself).
There are so many great developers and businesses out there that you could use as an example to model your business and software on. Use them, not Joel. Let Joel's business and opinions fade away as other smart, innovative companies run rings around his ageing product suite.
Someone approached hiwith the idea for that product, it wasn't his.
Besides, this is a perfect example of him contradicting himself about how taking VC is a bad idea.
Besides, do you think they are profitable yet? How do you think they will get there without heading down the Expert's Exchange track? And let's not forget how much chaff is now being added every day to these sites, it now seems to be impossible to ask a difficult question because only relative newbies seem to be the only ones answering questions.
I wish I could give you a 1000 up-votes for this. I'm so sick of hearing the rhetoric about language X not being able to scale.
Repeat after me, if your app doesn't scale it is YOUR fault, not a language, platform or framework. Scalability is about design and implementation, not what tools you use.
When you start out, you're designing your site in hopes that someone other than your mom is going to use it. Usually, all you need is an app server and a database. I you get successful, that won't cut it. You usually need to start adding more and more pieces and rethink some technology decisions you made originally.
I think I understand why the initial design/technology decisions would rarely make it to a product that has to be largely scaled. This makes perfect sense for almost all cases.
Do you think that there are technologies that are inherently more scalable than others, so if some body was initially choosing them would stand more chances to scale up in a non painful manner?
Worry about the "nobody cares enough" problem long before worrying about the "oh crap, too many people care" problem. User apathy, aka "not enough traction" kills far more startups than inability to scale. Pick the ecosystem with which your company will be most efficient and agile, and cross the scaling bridge if you come to it. We've rewritten substantially all parts of our codebase and key infrastructure 2 or 3 times in the last 8 years. You'll get the pleasure of doing the same iff you have users...
I completely agree with you. I think that in the 99.99% of the cases the question of scalability is related with a pseudo-problem or at best a good problem to have.
Bear in mind that developer experience and smarts count for more than anything else (if you don't have those yet, don't worry - they will come with time, patience, and effort).
That said, I would say that languages and technologies that help you achieve a more modular design will help you scale more. This makes it easier to tear things out and move them around so you can alter your architecture much more easily than you would otherwise. And of course efficiency (in terms of code performance) doesn't hurt either, but I wouldn't choose something on that alone. If you can have efficiency and modularity, so much the better!
It was Rails and, it wasn't that it wasn't unscalable but because they did it wrong then, they hired a bunch of developers that knew nothing about Rails, so of course they moved a lot of new and core development to other technologies.
It also had a lot to do with the fact that at the time Rails sites mostly ran on lighttpd or Mongrel, which was notoriously crashy (god was originally invented just to restart crashed Mongrels). From what I understand, at the time ActiveRecord hadn't yet been rewritten in C, which was also a big bottleneck for them (not to mention trying to scale MySQL to an insane level of traffic).
Nowadays, we have fancy stuff like Resque for background jobs, Passenger (aka mod_rails) for serving up Rails content, and a plethora of NoSQL databases.
ActiveRecord was never rewritten in C. Twitter's problems stemmed from the fact that they had written a realtime messaging system, but designed it like a microblogging platform. The design wouldn't have scaled well, regardless of the technology they used.
