[exabrial]

I would have liked to seen the Judy array implementation in pure Ruby, so we could compare apples to apples. I'm not trying to troll... but basically they solved their problem by:

* Avoiding Ruby language features

* Rewriting it in a different language

This is why I lean towards static languages like Go, Scala, and Java.

[pjmlp]

Have a look at Crystal as well.

https://github.com/manastech/crystal

[exabrial]

holy wow!

[twistedpair]

So if you want to run a big site on Ruby, slowly migrate all the Ruby bits you use heavily to C/++? Seems to be the storyline of their blog.

[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.

[dekz]

You're assuming that writing the code in a different language immediately makes it performant. Would you still not perform the following: 1) Write app in Go 2) Identify hotspots 3) Improve/rework code of hotspot.

[icebraining]

Their problem was mostly related to the choice of data structure and the object allocation and subsequent garbage collection, not dynamic typing. I don't see how any of those languages would have helped, except by having a better garbage collector, in the case of Java and Scala.