[quandrum]

Well, maybe to put it more generously:

1. Build a site in ruby (insert langauge/framework the creators are most comfortable/familiar with and can iterate quickly). 2. Build a community of a certain size that causes it scaling problems. 3. Identify the hotspots and re-implement them in more performant way.

This seems entirely reasonable to me. In fact, I'm guessing this is the path that all applications that get to Github scale take. Of course, it's easy to be snarky and identify Ruby as the problem. (Building the community is the hard part!)

[r00fus]

Back in my smalltalk days (mid-90s), we used to call this "going below the C level" - take sections of code that need to be optimized, and rewrite them in C as a DLL/shared binary, to be called by the smalltalk native layer.

The % of C code was less than 3%, from what I remember, and C is significantly more verbose than smalltalk, too.

I hear that happened a lot with java as well, using JNI sections for performance purposes (this was before hotspot compiler got decent).

[steveklabnik]

Bias alert: I have commit to Rails.

I think another bit that you've missed here is that once you have the users and are looking at scale, you've learned a lot about what you actually need. This fits well with all of the Lean Startup stuff: startups are an experiment.

In other words, before you're actually at scale, how do you know what your requirements are? Better to build things in something that lets you discover these requirements as quickly as possible, then fix an inconsistencies in what you've built, rather than try to imagine what your future requirements may be, build that, and turn out to be wrong.

To use one of the more famous examples of a pivot, if the Flickr team had spent a ton of time analyzing their anticipated needs for a game engine, that would have all been wasted when they pivoted to photo sharing.

On the smaller scale, if you asked me today why rendering GitHub's views is slow, I probably would have guessed that it's their SOA-style architecture, an overhead between components. I then could have wasted tons of time optimizing that, with little impact on what actually mattered.

But you can't take these measurements until you have a system that actually exists in the material world.