Something here doesn't sit right with me. Please don't launch into a lecture on algorithmic complexity and cache lines if you are running on Ruby on Rails.
Slow platforms are exactly where you need to talk algorithmic complexity. Switching to a faster environment would only reduce a routine's execution time by a constant multiplier—switching algorithms has the potential to do much more.
That's not what I mean. I think that any half-decent implementation in C would have been better than their current Ruby solution. And instead of spending all that time to research Judy arrays and other magic bullets, they could have already identified another problem zone and fixed it.
This just feels like "we have this huge and slow Ruby behemoth here, but using magic Judy arrays we made this little gear turn insanely fast!".
Execution time isn't the only cost in building software however. Building a web application in C may be "cheap" in regards to scaling performance, but it would sure as hell increase development costs a ton.
I think what Github has done is exactly what you're supposed to do: build your product on a platform that allows for quick growth and easy iteration, identify the slow parts, then swap those out for faster "gears" as you said.
Edit: I find it rather humorous that you find algorithmic research to be a magic bullet, but believe switching platforms to be a viable solution when faced with a bottleneck. I believe you have that backwards :)
I don't think parent is suggesting the whole website be written in C. I think parent sees the CS focus as a sideshow, and that a C version of the "escaper," even if not designed ideally, would still smoke the Ruby version that was acting as a bottleneck.
My point is that the CS is never a sideshow. Improvements gained from changes in algorithmic complexity vastly outpace improvements gained from switching languages/platforms.
Worry about your algorithm first and your platform second.
