[tom_b]

An intriguing part of the article asks about the Twitter Ruby-to-Java migration and posits that any language would be fine for a services architecture.

I'm not much of an object-oriented hacker, but when I was at larger IT firms, what several Java codebases shared was a common use of design patterns. It seems that this sharing of what may be considered a common vocabulary essentially makes it much easier for Java devs to jump into any project and follow the "accepted" usages in a way that perhaps other languages do not? So you are scaling up your dev team, it's infinitely easier to recruit acceptable Java candidates than say, Scala hackers? I do want to mention that my impression of Twitter is that there is definitely a polyglot JVM environment there (Scala, Clojure).

This feels like a bigger issue to me than I'd like it to be - in particular that Java programming opportunities vastly outnumber, say Ruby, Scala, Clojure, etc, hacking jobs.

[justinsb]

I believe that strong typing is a much bigger factor than design patterns in supporting big codebases, and allowing people new to the codebase to contribute productively. Once you go beyond a small project, it's really nice to have the compiler on your side here!

In terms of the pool of total developers, the argument is that "A-grade" developers use Scala and/or Java, "B-grade" developers only use Java, so a Scala developer is rarer but more likely to be an A-grade developer. But of course, once this is known then the B-grade developers learn Scala. This is probably what happened to Ruby - it was little known, so all the Ruby developers were 10x. Now everyone learns Rails, and Rails + Ruby teams are rapidly reverting to the mean.

But yes, I do agree that we've figured out what good Java code looks like now, although it took us 10-15 years to do so. And we haven't hit the 10 year mark on Scala, Ruby, Clojure etc...

[cageface]

Once you go beyond a small project, it's really nice to have the compiler on your side here!

Absolutely. Mobile dev brought me back to compiled languages after a long stint in Ruby and the advantages of static typing for performance, correctness, and tooling are so overwhelming that I doubt I'll ever work in a dynamic language by choice again.

[vidarh]

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.

[ssmoot]

Ruby is glacially slow.

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.

[jt2190]

  > As for the Twitter example... 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.

Perhaps it was more responsible to avoid investing millions of dollars and years of effort in an over-architected system and just ship something quick and dirty, and see if people like it. All of us developers fantasize about the "write once, runs forever" system, but the reality is that the real requirements of any system are constantly changing, and we have to keep adapting, rewriting and re-architecting just to keep up.