Scaling is more about sound architectural decisions than it is about stack.<p>(And it is more about "not a problem" than it is about architecture, because a gigantic proportion of all startups will never have any scaling problem to speak of, and the majority of the remainder will be able to solve theirs in fairly boring fashions.)<p>Almost all startups would be better served by playing around in their technology of choice looking for something that could possibly cause a scaling problem rather than planning for scaling problems.
Can you name a single startup that failed because of their inability to scale?<p>Development speed is way more important than scalability. Like Paul Graham says, the vast majority of startups fail because they make a product no one wants or because they never launch a product in the first place. Faster software development means you figure out if your product is a dud faster, and you're less likely to run out of morale before you've got something substantial.<p>I've been working on my current (unreleased) project with Django and jQuery on Linux for about a month. Here's all of the stuff I've made use of from the Django, jQuery, and Python communities:<p><a href="http://code.google.com/p/django-command-extensions/" rel="nofollow">http://code.google.com/p/django-command-extensions/</a><p><a href="http://south.aeracode.org/" rel="nofollow">http://south.aeracode.org/</a><p><a href="http://github.com/dcramer/django-ratings" rel="nofollow">http://github.com/dcramer/django-ratings</a><p><a href="http://github.com/pydanny/django-uni-form" rel="nofollow">http://github.com/pydanny/django-uni-form</a><p><a href="http://github.com/robhudson/django-debug-toolbar" rel="nofollow">http://github.com/robhudson/django-debug-toolbar</a><p><a href="http://github.com/alex/django-ajax-validation" rel="nofollow">http://github.com/alex/django-ajax-validation</a><p><a href="http://fabfile.org/" rel="nofollow">http://fabfile.org/</a><p><a href="http://orkans-tmp.22web.net/star_rating/" rel="nofollow">http://orkans-tmp.22web.net/star_rating/</a><p><a href="http://jquery.malsup.com/form/" rel="nofollow">http://jquery.malsup.com/form/</a><p><a href="http://plugins.jquery.com/project/ScrollTo" rel="nofollow">http://plugins.jquery.com/project/ScrollTo</a><p><a href="http://jashkenas.github.com/coffee-script/" rel="nofollow">http://jashkenas.github.com/coffee-script/</a><p><a href="http://code.google.com/p/modwsgi/" rel="nofollow">http://code.google.com/p/modwsgi/</a><p>There's no way I could ever use a niche framework after having drunk this reusable code kool-aid.<p>Even if Django weren't scalable, if I really was on the road to being the next Facebook or Youtube, there'd be plenty of time and money to rewrite in something that <i>could</i> scale.
1. caching<p>2. prefer static content over dynamic, as much as possible<p>3. lots of machines, with the requests distributed across all of them<p>these 3 strategies alone will buy lots of scale
We use Django, Linux (Ubuntu for both servers and developer machies), PostGIS database, memcache, Apache, etc. and of course Eclipse, Trac, etc. etc.<p>Haven't reached 1M hits per day yet, but I'm about to experience a bit of preemptive load testing to find out where the initial problem spots may be.
Rails, distributed erlang with a BERTRPC endpoint, memcache, redis, thin/sinatra/eventmachine. The key is the less work you have to do in the request response cycle and the more you can offload to better suited environments/servers, the easier time you will have adapting to new challenges.