{"id":2270,"date":"2009-04-02T19:53:00","date_gmt":"2009-04-02T19:53:00","guid":{"rendered":"https:\/\/ikaisays.com\/?p=2270"},"modified":"2021-04-20T19:53:44","modified_gmt":"2021-04-20T19:53:44","slug":"twitter-ruby-on-rails-scala-and-people-who-dont-rtfa","status":"publish","type":"post","link":"https:\/\/ikaisays.com\/2009\/04\/02\/twitter-ruby-on-rails-scala-and-people-who-dont-rtfa\/","title":{"rendered":"Twitter, Ruby on Rails, Scala and people who don\u2019t RTFA"},"content":{"rendered":"\n

The Register recently published an article titled, \u201cTwitter jilts Ruby for Scala<\/a>\u201c, prompting a wave of Tweets (Twitter messages for the jargon challenged) about Ruby on Rails and scaling. More specifically, its lack of ability to do do. The source of this article was a talk given by the API lead at Twitter, Alex Payne, at the Web 2.0 Expo in San Francisco, where he discussed porting parts of Twitter from Ruby to Scala. Naturally, the armchair commentators added their two cents about the message, taking it to mean that Scala is *the* one true language for internet companies, and that Ruby on Rails should not be used because it cannot scale.<\/p>\n\n\n\n

I tweeted about my annoyance with retweeters that don\u2019t understand what they are retweeting, and Alex responded<\/a>: \u201cIt\u2019s really frustrating for me. I don\u2019t think the people who were there for my talk got that impression. The press skewed it.\u201d<\/p>\n\n\n\n

Alex wasn\u2019t saying that Rails can\u2019t scale. Alex was saying that he really likes Scala, and parts of Twitter that were written in Ruby were rewritten in Scala because some tasks are simply not appropriate for Ruby. I know of Kestrel<\/a>, their messaging queue, but likely there are other middleware layers that sit between their APIs\/web interfaces and their data sources that are being ported.<\/p>\n\n\n\n

Now, Scala is an amazing language. It compiles to JVM bytecode, and thus, most procedures will run near or at the speed of Java. Functions can be treated as first class objects and passed around like variables. Its system of type inference means less ceremony for simply declaring variables. Traits function remarkably like mixins in dynamic languages, allowing very rich composite classes that, in many cases, need to add very little boilerplate for the composition, unlike Java interfaces. And pattern matching with wildcards? I can\u2019t even think of an analogy for how powerful of a tool this is. Is it the best compiled language? Some think so, and I can certainly see where they are coming from. I\u2019m learning Scala as we speak. The basics were pretty easy to pick up, but I\u2019m still struggling to be good with it. Scala best practices such as programming in an immutable style are far easier to preach than to actual do.<\/p>\n\n\n\n

But Scala is not Ruby, and will never be Ruby. Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth. You can take an Integer and declare more methods on it. Duck typing means that you don\u2019t have to set up boilerplate interfaces and abstract classes to create objects that can replace other objects with similar interfaces. A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby. Imagine this: a developer looks at a model file representing a database table, and immediately understands the business rules regarding validity as well as the callbacks that will take place when the object is created, updated or destroyed. Or this: it is possible to create a plugin that extends collections objects to allow very complex pagination, and a client developer only has to include a file or remove the include statement. This plugin recognizes if the collection in question maps to a database, and if so, applies LIMIT and OFFSET statements to SQL queries as to not eagerly load too many objects at once. This plugin exists<\/a>.<\/p>\n\n\n\n

This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM<\/a>, and he improves Ruby performance by as much as twenty times by removing much of Ruby\u2019s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch.<\/p>\n\n\n\n

So if Ruby is slow, and Rails uses Ruby, does that mean Rails cannot scale? Let me make this clear right now: Though Ruby is slow, this does not mean that Rails does not scale.<\/strong> Scalability is a very difficult concept, often oversimplified to be synonymous with efficiency. Efficiency is a facet of scalability, yes, but it is not its only dimension. Reliability and uptime are very important dimensions of a scalable system. So is horizontal scalability: the ability to serve an increase in usage with a corresponding increase in computational nodes. Though it may seem like a given that throwing hardware at a problem will increase capacity, this simply isn\u2019t so. Anybody that has worked on a large data driven application will tell you that a centralized, authoritative source such as a database cluster is a bottleneck, and simply throwing hardware at the problem results in diminishing marginal returns. Then there is quality of service. A truly scalable architecture will have minimal service degradation as users and usage exponentially increase.<\/p>\n\n\n\n

I use the word \u201carchitecture\u201d because a truly scalable system that meets the requirements set by its intended consumer is rarely, if ever, about a single component. Even if we were just talking about speed and none of the other dimensions of scalability, there\u2019s a great article by Joe Stump where he calls out language critics about this exact subject<\/a>. C++ can probably assemble HTML at least a hundred times faster than Ruby, but this has minimal impact on what a user sees because disk reads are slow, talking to a data source is slow, and sending data over the internet is *really* slow. On top of all that, Steve Souders, creator of YSlow<\/a>, a popular tool for benchmarking perceived speed of web sites, argues that for most sites, 90% of the wait time a user has to put up with is a result of loading assets, JavaScript and stylesheets. Rails and proper database constraints can ensure data integrity (reliability). Rails is by default stateless and sessions can be centralized (fault tolerance and horizontal scalability), check. Rails can scale, and does scale. Twitter is not replacing their web tier because it is fast enough, and they have focused on optimizing their middle tier, which sits between their web layer and their data layer. There\u2019s no point in replacing this layer. Its performance and reliability are completely bound by the data and middleware layers.<\/p>\n\n\n\n

This is where Scala enters the picture: middleware. Likely this refers to a non-RDBMS datasource serving denormalized social graph, a dispatching component for pushing messages through SMS and email, a queue and queue workers. There are a few requirements here: concurrency and computational speed, both of which are areas where Ruby falls flat because MRI Ruby, the stock VM, uses green threads which block on I\/O and do not make use of multicore processors. In addition, Ruby\u2019s memory requirements are aggressive. Scala, on the other hand, is fast and can is as concurrent as the JVM will allow, which is pretty damned concurrent.<\/p>\n\n\n\n

So what Twitter did was optimize the bottleneck and leave their investment in the front-end intact. This shouldn\u2019t surprise anybody. Facebook started out on PHP, but now their backend is an amalgam of C\/C++, Erlang and other languages. Google runs Java and C++ for their backend, but I\u2019m told several web tier services are written in Python. And so forth. This doesn\u2019t mean don\u2019t use Python, and don\u2019t use PHP. It just means to be ready to optimize and possibly to replace those components when the time is right, which, for many startups, is a LOOOOOOONG way off.<\/p>\n\n\n\n

In fact, I still push Ruby on Rails as the development platform of choice for web startups launching a 1.0. Why? There are many reasons. Here are a few:<\/p>\n\n\n\n