After nearly two years of high profile scaling problems, Twitter is planning to abandon Ruby on Rails…
As a Django fan and evangelist, I admit it would give me great pleasure to see this as a colossal failure for Rails, point, laugh, and generally poke fun at all the Rails fanboys and girls.
But let’s be real for one minute. Twitter doesn’t suck because of Rails. Twitter sucks because they have ridiculous amounts of traffic (especially to their API and SMS gateways), a limited ability to cache (a non-realtime Twitter is a pretty useless Twitter), and (as far as I can tell), they’re not making any money, so they probably have limited resources to pour into more hardware.
The bottom line is that Twitter will probably cause major scaling problems for any platform, be it Rails, Django, Java, .NET, PHP, or tin cans with a string tied between them. Ruby is undeniably slow compared to Python, Java, and PHP, but I really doubt the problems Twitter deals with are at the Ruby level, anyway. Much as I wish they weren’t, anyone who says Twitter sucks because of Ruby on Rails is either foolish or joking.
Twitter sucks because of Rails. Just joking. Visit site »
March 12th, 2007, 6 PM in Austin, TX
Have to agree with James’ response to Twitter developer Alex Payne’s Shared Hosting is a Ghetto. Visit site »
Sweet. Looks to have several major feature additions. Congrats to David and the whole Rails community! Visit site »
Webfaction, my favorite Django host, has drastically improved its plans (and redesigned its website). They now offer unlimited websites, domains, e-mails, databases, and applications on all plans — plus, they’ve increased the amount of bandwidth, RAM, and disk space each plan gets.
Besides being great at Django, WebFaction also does Rails, TurboGears, and several other modern development environments.
Booyah! Go getcha some WebFaction! Visit site »
Yet Another Django Template Language Ripoff for Ruby on Rails. There sure seem to be a lot of these for a framework whose creator hates template languages. :)
But seriously — it looks like it does most of what Django’s wonderful template language does, so if you’re a Rails guy, give it a look. Visit site »
A port of Christian’s typogrify for Rails. Since my post about typogrify here, I think it’s been ported to just about every web development language under the sun. Awesome. Visit site »
James has a nice post about choosing a web development framework, and especially about switching from J2EE to a dynamic language and framework like Ruby/Rails or Python/Django. Visit site »
After Typogrify for Django, the Rails camp wants good typography, too. :) The widon’t here won’t work on chunks of HTML like the Django variant will, but it’s still a lot better than nothing. Support good typography! Visit site »
A bunch of great presentation slides from this year’s conferences are available at the RailsConf website. Even though I’m not a Rails guy, per se, most of this stuff is equally applicable to development with other LAMP-ish agile development frameworks. Visit site »
Wow, definitely didn’t expect this. Connector is an amazing web app that I’d definitely love to be able to run a local version of and extend for myself. Awesome news. Huge boon to the Ruby and Rails communities. Visit site »
Alex has a lot to say about Twitter, Rails, and scaling. Not to Rails-bash, but it’s hard to ignore these quotes:
Running on Rails has forced us to deal with scaling issues — issues that any growing site eventually contends with — far sooner than I think we would on another framework.
And…
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.
And…
It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.
Props to Alex for being upfront and forward and not sticking to the Rails party line of “it’s fast enough.” Alex is obviously in a unique situation, as Twitter is the biggest Rails app on the web. Rails, which is a great framework in so many ways, will probably work great for your site, which is almost certainly not as intensive as Twitter.
But until the performance can scale to a huge site, people are always going to be a bit scared to use it for a startup they perceive as “the next big thing.” Visit site »
If you’re going to the Web 2.0 conference in SF next week, be sure to check out Adrian’s presentation about Django. You know you want to! Also, there’s a comparison of web app frameworks panel that looks like it should be good (includes members of both the Rails and Django teams). Visit site »
The latest app from 37signals looks like another beauty. You can get a limited free account, but it seems like you have to pay $50/mo. for the cases feature, which seems like the most killer part of the deal. Nonetheless, $50/mo is a small price to pay for someone who really needs this kind of app (and there are lots of those people). All in all, looks great — which is no surprise, judging by the quality of the other 37signals apps. Check it out. Visit site »
Only a few of these good tips are actually Ruby/Rails-specific. Most of them can apply to development using any MVC-style web application framework. Some might be obvious, but still — good stuff. Visit site »
In choosing a framework, a web developer does a exhaustive series of performance tests, comparing Django, Ruby on Rails, TurboGears, CodeIgniter, Symfony, and Catalyst — and publishes the results. As with all benchmarks I’ve seen, Django is the clear winner. Visit site »
Although it’s not exactly what Jason is saying in his post, I think the spoon/jackhammer comparison applies even more directly to agile web app framework versus monolithic Java environment discussion. Rails is their spoon. And if Rails is a spoon, Django is a spork. :) Visit site »
Probably the best comparison of these two popular web app frameworks I’ve seen. These guys wrote the same app twice — once in each Django and Rails — and analyzed the results. They provide no clear winner — but do outline several “choosing points” that will help you pick between them. For example: Already know Ruby? Choose Rails. Need super-simple AJAX? Choose Rails. Does your team include non-programming web designers? Choose Django. Need automatic admin pages for editing your content? Choose Django. Both the slides are paper are terrific. Check ‘em out. Visit site »
Looks like a very nice publishing platform. Uses Liquid, the Ruby/Rails port of Django’s template language. Powers Boxes and Arrows. Visit site »