| My experience with Java vs. Ruby is that Java applications are full of common design patterns because they "have to" be. Design patterns that are often considered necessary in Java, are often pointless or considered bad practice because of unnecessary complexity in other languages. It may be easier to recruit java devs, but because more people have learned Java, not because it's easier to jump into new projects. That may be a valid reason to pick Java (I've picked PHP in the past, despite preferring Ruby, exactly based on the availability of "good enough" developers versed in the language). As for the Twitter example, pretty much everything that has been publicly discussed about their original RoR app made it sound like a god-awful abomination in terms of architecture. OF COURSE it didn't scale. It seems to me at least that blaming Rails or Ruby or both is just a convenient way to avoid responsibility for the architecture and/or a convenient excuse for people that wanted to switch to Java/Scala/Clojure to use to justify the rewrites. I've posted examples in the past on how they could have scaled it using Ruby, based on my own experiences with pure-Ruby queueing systems that would've been "simple" to scale even to their current size. As I've also pointed out, the primary thing they were trying to scale - messaging with potentially massive fan-out - is a well understood and "solved" problem: Turn your flat distribution lists into trees where each recipient is either a follower or the location of a subtree, and you can scale it arbitrarily. In practice, only a very small percentage of their users are "special" enough to require the "tree" treatment, to the point where you can handle it as a special sub-system. [Heck, you could scale the foundation of Twitter with a bunch of mail servers and shell scripts to manage forwarding lists (no, it would not be costs-effective, but I have done high volume message queueing with mail servers before).] Note that I'm not saying that another language might not be better for them - at their scale, it pays to optimise things that'd be a rounding error in a smaller environment - but at least their original RoR complaints were ludicrously off the mark. They might very well have valid reasons for switching, but the reasons they used to give were not it. |
People try really hard to not accept this, and blame "architecture", but yeah, no.
You can read up on templating benchmarks from the very early days of Rails. You can easily spend tens of milliseconds just in template rendering.
The reason ActiveRecord, DataMapper, et all went with multiple Database round-trips had nothing to do with efficiency for the database and everything to do with Ruby's extreme performance deficits. A language so slow that a few thousand objects, with a dozen fields, and a relation, causing a couple million method calls during materialization would bring the interpreter to it's knees.
And now you've filled your response cycle with forced synchronous roundtrips to external services.
You don't even have the option to think about pure architecture. You're working under real constraints that don't just go away. Everything's got 'em, but the point where you have to start worrying about those kinds of issues in your average app in Scala is 100X later.