Follow Slashdot stories on Twitter


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×
Social Networks The Internet Programming IT Technology

Twitter Reportedly May Abandon Ruby On Rails 423 423

Raster Burn writes "According to TechCrunch, Twitter has plans to abandon Ruby on Rails after two years of scalability issues. Candidates to replace Rails are said to be PHP, Java, and Ruby without the Rails framework." The post links a brief comment (at 139 characters, probably a tweet) from Twitter founder Ev Williams saying it ain't so. The comments following the post embody the controversy over whether or not RoR sucks.
This discussion has been archived. No new comments can be posted.

Twitter Reportedly May Abandon Ruby On Rails

Comments Filter:
  • by drix (4602) on Friday May 02, 2008 @11:49AM (#23275572) Homepage
    How complex can Twitter be on the inside? In the 1.5 years they've been publicly grousing about Rails they could have redone it ten times over.
  • by caramelcarrot (778148) on Friday May 02, 2008 @11:49AM (#23275576)
    They're a very high volume site.
  • by nine-times (778537) <> on Friday May 02, 2008 @11:57AM (#23275680) Homepage

    I think it is one of the most usless things on the face of the earth but it seems popular for some strange reason.

    Most popular things are useless.

  • Ruby Can't Scale (Score:5, Insightful)

    by Foofoobar (318279) on Friday May 02, 2008 @11:59AM (#23275714)
    And for all those Ruby people in denial to the fact that people have been saying this for years, here is your proof yet again. Of course I will be marked down as being a troll for pointing this out by the RUBY comunity but it is time that they acknowledge the inherent achilles heel of the language.
  • by revscat (35618) on Friday May 02, 2008 @12:03PM (#23275780) Journal

    Rails was the cat's pajamas two years ago. The future. The in-thing. Revolutionary. Exciting. Radical. Amazing!

    Then like so many similar times before, reality set in. It turned out to be buggy, unstable, less performant, and heavily dependant upon an evangelical base.

    Ruby the language is interesting. Not my personal cuppa, but I have nothing against it. Rails, however... After having analyzed it and developed a prototype application for my company, I came to realize that there are other frameworks out there that are more worthwhile, epecially in an enterprise environment. The problems I've seen Twitter experience only solidify this.

    If you are doing green-field development Rails should probably not be your first choice. Yes, Rails is interesting. No, it is not the end-all-be-all, and it certainly has some rather major warts.

  • by Penguin Programmer (241752) on Friday May 02, 2008 @12:42PM (#23276330) Homepage
    I think Twitter has probably done it right: use the clean architecture to build the app cleanly and quickly, then put developer cycles into making it fast and efficient, possibly losing some of the niceness of the architecture in the process.

    That said, I don't really think that clean architecture and speed are orthogonal goals. Frameworks like Rails add overhead because they are general - they allow you to do all sorts of things on top of them, and still support all those things even when you're only using some of the functionality. You can maintain your clean design while improving efficiency. What you lose is the ease of adding new features, since you strip out the generality and agility of the framework.
  • by ubernostrum (219442) on Friday May 02, 2008 @12:44PM (#23276364) Homepage

    You're obviously underestimating the amount of effort it takes to store usernames, passwords, and phone numbers in a database, then associate them with messages no more than 120 characters in length

    Yeah, because message queues and SMS gateways and email-parsing daemons just write themselves, freeing you up to belittle things on Slashdot!

  • by vux984 (928602) on Friday May 02, 2008 @01:08PM (#23276694)
    On the other hand, perhaps the bottlenecks are somewhere inside the Rails framework, and the Twitter team thinks that it'd be simpler to move to a new framework than to invest the effort to fix Rails.

    That would be the crux of it, as I read it.

    The rails framework is aptly named. Its like driving a train. You follow the rails. Its easy, simple, and those are its strengths. But if one day, you decide you want to cut across a field save a few hours of travel, well, you probably shouldn't have chosen 'train' as your mode of transportation.

    The simpler and easier a framework is the harder it is to change its behaviour in ways the designers didn't expect. Its like using Microsofts web rendering controls in an application... they are drag and drop simple to use and that's great. But if you want to tweak them so they handle a particular css element in a different way [read standards compliant way], its not going to happen. The -best- you can hope for is to pre-parse the document to rewrite it in a way that the rendering control will get the appearance right, because you are NOT going to change the rendering behaviour itself easily. Better by far to just switch to a different rendering engine.

    Conversely the more robust a framework is, and the more hooks they give you to inject/alter behavior, the more complicated and bug-prone it is to develop with.

    Rails is a trade off... great when it fits what you need, abysmal when it doesn't. And rails in particular from what I've heard is especially frustrating when its 'oh-so-close-but-not-quite' what you need.
  • by samkass (174571) on Friday May 02, 2008 @01:12PM (#23276740) Homepage Journal
    While system responsiveness is often a product of optimization, scalability rarely is. When a system can scale across orders of magnitude, it's because of a clean, maintainable architecture that allowed components to be completely revamped and swapped in, identified and eliminated high-polynomial (or worse) growth patterns, and allowed more developers to be spun up on it fast enough to keep up with demand.

    On the other hand, if you spend all day pondering the ultimate architecture, you'll never ship and if you do you won't meet requirements. Learning where those tradeoffs are is all about experience and is why the engineers with over a decade of real world experience earn more.
  • by CommandoCody (1154955) on Friday May 02, 2008 @01:14PM (#23276760)

    So, er... TechCrunch says "multiple sources claim that Twitter is abandoning RoR."

    The guy who founded Twitter says, "no, not really."

    And TechCrunch says, "but we have MULTIPLE SOURCES."

    Guess what? I have MULTIPLE SOURCES that say the Earth is flat!

    Must be a slow news day.

  • by Bogtha (906264) on Friday May 02, 2008 @01:17PM (#23276792)

    Yeah, because message queues and SMS gateways and email-parsing daemons just write themselves

    Twitter don't use Rails to handle most of that though, do they? I don't think drix is suggesting that they rewrite every piece of code they have, just the Rails portion.

  • by Anonymous Coward on Friday May 02, 2008 @01:30PM (#23276970)

    What is more important? Is developer time and productivity over the software lifetime more valuable than CPU cycles? If the price of that productivity imposes a maximum limit on performance, how much optimization should be undertaken?

    It's a hard question to answer. On the one hand employees are expensive and hardware is cheap. On the other hand, you can't simply forego developing for performance just because of some religious belief that architecture should be clean.
    This position presents a false dichotomy: a choice between achieving passable performance through good design, versus optimizing for developer efficiency. Efficient use of resources and ease of development are not mutually exclusive -- why should they be?

    When developers say "Hardware is cheap" in response to poor architectural choices, what they're really saying is that "Our hardware costs are externalized".

    This has little to do with "speed, memory, and response time at all cost", and everything to do with architecting for your problem space, avoiding grossly inefficient architectures -- you must model the natural concurrency of the system, use only the RAM you need to get the job done (not the RAM you need to run 50 duplicate interpreters), etc.

    The basic architecture of shared nothing, fork()-based scaling in Rails is flawed in this regard, and that has little to do with developer productivity and everything to do with poorly thought out architecture, and poorly implemented abstractions.
  • by Anonymous Coward on Friday May 02, 2008 @01:33PM (#23277006)
    Well for starters, active record and the notion that everything always should go to the database. In the rails world, caching refers to page generation where in like the ASP and J2EE worlds, there is also data caching from the database. On your desktop, with your blog, a database query is cheap and fast, on a real system it can be expensive and slow. Active record is remarkably chatty to begin with. If you can make the database fast enough then in theory you can have an army of rails servers blasting it for every page hit, that's hard to do though, very very hard when you reach certain volumes.

    No threading or service module notion. Everything is tied to servicing a web page. Long lived jobs mean long lived web page renders. It also forces you to scale via page hits scaling rather than in other ways. There are more fined grained ways to break tasks up to scale.

    Ruby itself is kind of pokey at a lot of things. Sure it's "fast enough" for a lot of things too but are you sure its "fast enough" for the things you intend to do? Or will you write them in some other language and then interface and shim it in? Which may make it perform faster but take a different amount of development time. The scaling of dev time is also a variable, not just the upfront zero to a database CRUD time, but zero to a delivered product time and then the next release time.

    The short of it, if you ask me, is a more fundamental issue: it's just not built for big tasks. The architect(s) of Rails approach enterprise software and the various technologies to build it with disdain and look at it like a lot of meaningless engineering for the sake of engineering. There is definitely a dose of that that actually exists in the world but you're a complete fool if you think that the industry as a whole has arrived where they are in that regard without need. There are a lot of high volume, high performance j2ee systems out there that don't do a lot of exotic things; there are no high performance Rails sites that don't do almost everything in an exotic fashion. That all begs the question to me... There is no "Rails way" to do high performance. Unless that means completely unconventional and custom.

    That being said, fire up Rails or Grails [] (if you go that way) and bang out some AJAX enabled CRUDs and I promise you, you'll fall in love with it. Compared to setting up some EJB (pre v3) and building some servlets, it's a fucking dream.

  • by ivan256 (17499) on Friday May 02, 2008 @01:46PM (#23277188)
    You don't have to RTFA. Just read the fine summary:

    Candidates to replace Rails are said to be PHP, Java, and Ruby without the Rails framework.

    If the language were a problem, then Ruby without Rails wouldn't be an option, now would it? Think about that, genius.

    And actually, I'm not a ruby developer. Nice try though.
  • by LurkerXXX (667952) on Friday May 02, 2008 @02:05PM (#23277462)
    Or you could just email them all.

    Unless you are claiming there are a substantial percentage of folks who use twitter but don't use email. I'll want citations for that though, because I don't believe it for a minute.
  • by DragonWriter (970822) on Friday May 02, 2008 @02:36PM (#23277902)

    My tests confirm it is 20 times slower than python in simple loops. /blockquote

    Since in many simple tests, JRuby and Ruby 1.9 are 10+ times faster than Ruby 1.8, I wouldn't be really impressed that on some simple tests Python is 20x faster than Ruby 1.8. Not that any of the speed tests in the tables on the linked page show a 20:1 ratio in either direction between Python 2.4 and Ruby 1.8; and the only one that is over 10:1 in favor of Python doesn't use similar methodology in the Python and Ruby tests.
  • by hairyfeet (841228) <bassbeast1968&gmail,com> on Friday May 02, 2008 @03:47PM (#23278828) Journal
    Uh,thanks,but if you'd read any of my past posts you would know(probably to your horror)that i wasn't trolling. When you need to whip off a simple interface to a database EXTREMELY fast for a little Mom&Pop shop IMHO nothing beats VB6+either Access or MySQL(depending on what is handy and the size of the shop).

    I know it isn't considered trendy,although "Good Old VB6" is still in the top 5 of programming languages(number 3 to be precise) and as long as you aren't trying to build some gigantic multi-use program it really works great. Of course I've been using BASIC since the days of the VIC 20(recording my programs to a cassette,boy THAT was fun) so for me it just works.YMMV of course and I've known guys that can do the same in Java,C++,etc. IMHO if it does the job you need it to and the customers are happy I say go for it.

  • by LurkerXXX (667952) on Friday May 02, 2008 @04:06PM (#23279040)
    Instead they are tied to a twitter site. imagine that!

    6 of 1, half a dozen of the other. Sorry, I just don't see any amazing reason to use twitter over email for that kind of stuff.
  • by Irish_Samurai (224931) on Friday May 02, 2008 @04:25PM (#23279302)
    They have figured out how to monetize it.

    Actually, all of these free social networking services have figured out how to monetize it.

    Twitter is the honeypot to collect a group of users. After a density of users is reached, larger communication companies will start looking at purchasing Twitter so they can "integrate" their service. Nevermind that integrating a free service with an available API doesn't require purchase.

    What the larger company is actually doing is buying customers.

    From the TOS:

    Business Transfers Twitter may sell, transfer or otherwise share some or all of its assets, including your personally identifiable information, in connection with a merger, acquisition, reorganization or sale of assets or in the event of bankruptcy. You will have the opportunity to opt out of any such transfer if the new entity's planned processing of your information differs materially from that set forth in this Privacy Policy.
    Build Service - Grow Userbase - Sell Demographic data.

    It's the web 2.0 business model, all coated in a lovely veneer of altruistic "doing it for the love of geekiness" bullshit.
  • by achacha (139424) on Friday May 02, 2008 @04:36PM (#23279452) Homepage
    Personally I would never run a high volume site on top of a scripting language platform. While RoR is pretty nice on getting a site up and running and integrated with a database, it is still poor in the scalability department.

    For a medium to large site they should consider using servlets and java and avoid J2EE.

    For a very large site I would recommend C/C++ and maybe java if they have the budget for hardware.

    The toughest part is getting developers that can code webapps (not just CGIs) in C/C++ (while easy to do C/C++ developers overall are hard to find and are not as cheap as ruby/perl/python ones and even java ones; this is from experience of trying to hire them). So they should check their developer base and see what is the fastest language they feel very comfortable with and go with it. From experience they may have to settle for java since that will provide them a large pool to pick developers from and the learning curve is slightly less steep than C/C++.

    I suspect they fell into the trap of building a demo fast using RoR and then just going with it into production, I have seen this way too many times unfortunately.
  • by bill_kress (99356) on Friday May 02, 2008 @05:41PM (#23280078)
    Premature Optimization is the root of all evil.

    I've never seen anything saying otherwise.

    Follow any of these sets of rules: [] [] []

    Or my version--
    1) Don't optimize, no really, don't.
    2) If you absolutely have to, write it unoptimized, test it, write it optimized, then:
    2a) If the first is anywhere in the ballpark, throw away the second,
    2b) If the second has enough of a proven, documented speed gain to get you past some accept/no accept barrier, comment out the slower one, but keep it so the next guy can follow the "Good" code.

    If you don't document exactly what you did in the code and why, I'm going to refactor it into something readable the second I see it.

    Also--know how to program. Choosing a linked list instead of an array list for an insertion sort is just programming correctly. It's not an optimization.

    -1 offtopic... Just wanted to help the parent out with his cow-orker.
  • by fm6 (162816) on Friday May 02, 2008 @07:17PM (#23280812) Homepage Journal

    C/C++ fastest way to execute web apps but also more difficult
    If all your web apps are faster with C/C++, you must run some very strange web apps. The efficiency of C++ comes from the fact that it compiles to machine code. Machine code only has an advantage when the CPU is the bottleneck. What kind of web application is CPU bound? Network and disk, more likely.

    And indeed, your experience differs a lot from that of thousands of web developers. Perl in particular had been called the Duct Tape of the Internet.

    Speaking of Perl, I notice that your complaint it is not that it's slow, but that it's hard to support. That's a legitimate complaint, but it says nothing about the relative efficiency of scripting languages.

OS/2 must die!