Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Social Networks The Internet Programming IT Technology

Twitter Reportedly May Abandon Ruby On Rails 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 sm62704 ( 957197 )
      Horizontal scrolls in 1024x768? What a lamer! If that guy wants me to read a web page about technology he'd better learn to code a fucking web page. I mean jesus, HTML ain't exactly assembling machine code by hand.

      Does anybody have a javascript snippet to automatically go back a page if the idiot who wrote the page you landed on has a horizontal scroll? I'm too lazy to write the two lines needed (actually you could probably do it in just an anchor tag).

      Even though I didn't bother reading the page, It was in
    • by xant ( 99438 )
      And check out Zed's new book:

      http://www.oreillymaker.com/link/6313/rails-is-bullshit/ [oreillymaker.com]
  • by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Friday May 02, 2008 @11:51AM (#23275608)
    I have an argument with a coworker frequently about architectural orthogonality vs performance. I fall on the "architecture should be clean and easy to understand and maintain" side of the argument and he falls on the "speed, memory, and response time at all cost" side.

    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.
    • Frankly, I think Twitter is doing the wrong thing here. Its a very rare case for the actual architecture of the program to inhibit performance. Usually, the bottlenecks occur in one or two suboptimal modules, that, when optimized, significantly increase program speed.

      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.

      • Yes, I bet you're right... I'm sure the Twitter people have never heard of profiling before.
      • 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.
        • I'm just starting to muck about with Rails, and am interested in where, exactly, it fails miserably. Not trolling, just curious.

          Thanks.

          • Re:Examples? (Score:5, Interesting)

            by beldraen ( 94534 ) <chad...montplaisir@@@gmail...com> on Friday May 02, 2008 @03:15PM (#23278462)
            Having worked with Rails for a year, I have found listening to people who talk on any web forum about any language draws out nothing but hyperbole. So, I would take most of what is said here with a grain of salt since it is obvious that most of the people commenting here are stating "truths" from religious wars.

            The framework operates a multiple levels. At the highest, a complete page can be generated from scaffold that automatically hook model to controller to view. I have found the scaffolds to be lack luster. From a completely database-centric view, there are some neat things that are automatically generated. For instance, verification methods in models are use to display errors on the page and mark input fields in red. My personal experience has found scaffolds to be lackluster.

            Most well-designed applications revolve around the application's use, not its internal data representation. Using scaffold strongly ties the interface to data representation which creates the situation that "the user can be wrong." You see this in Microsoft Access databases where you can enter something in or choose options that are mutually exclusive. Because the application lets you see that data, the program generates an error if you are wrong. From what I have seen, the gripe is that the full scaffold is too specific and rigid. Well, duh?! That's the point of each layer of scaffold--to provide a guide for usage.

            Personally, I have shunned most of the page scaffolding and tend to rely on creating my own use flow. I use the controllers to present that choices are possible and to manipulate the models as opposed to the common practice of having the controller just load a set of records and pass it to the view (which formats the output). The advantage is that the user is never wrong. Options that are logically inconsistent are never presented. Add to this the ability to monkey-patch (the extension of predefined classes) and lambdas, the code is clean and concise. Both can be used to refactor procedural code into functional code and move it out of the controllers and models. Most importantly, the design allows you to think about what you want to manipulate and then after the fact extend the functionality. A common example of the is the statement:
            1.day.from_now
            The numeric class is extended in Rails so that you do not have find and use a static date class, but can state simply the desired result.

            So, where does it fail miserably? So far, I have not found any great place that it does. It performs as well I need it to serve about a dozen users on a lowly Pentium 4 machine with 256 megs of RAM. So far, the application has been 99% maintenance free. A date verification package I am using had a Feb 29th bug in it. The cool thing is that since I can see the source, I could fixed it. Perhaps there are issues with scaling, but from what I understand, the system was designed around a non-centric design. In theory, a correctly designed application should be able scale horizontally.

            Given that there are other high-profile, high-use web sites written in Rails that do not suffer from Twitter's issues, I am left thinking that its failure in general looking for a specific reason. Rails has been very stable and easy to extend, but then I write for maintenance and ignore hype.
    • Re: (Score:3, Insightful)

      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
    • by nuzak ( 959558 )
      > Is developer time and productivity over the software lifetime more valuable than CPU cycles?

      For development, you bet it is. For production, I'd rather pay developers to work on a faster platform than have to purchase and manage five times more hardware just to make the thing scale. The "hardware is cheap" argument runs hollow when you start literally running out of data center space all because the software is crap.
    • 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.
    • I have an argument with a coworker frequently about architectural orthogonality vs performance. I fall on the "architecture should be clean and easy to understand and maintain" side of the argument and he falls on the "speed, memory, and response time at all cost" side.

      I prefer: use "architecture should be clean and easy to understand and maintain" until it starts to fly, then rewrite crucial parts as in "speed, memory, and response time at all cost"

      It's not rocket sience really.

      all those frameworks help

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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

    • This argument is relevant. I cannot speak for twitter but I have seen many a company develop a poor architecture in-house, experience poor results, rewrite the whole thing at great cost, and blame the technology instead of the architecture for political reasons. It's an easier sell to the CEO to ask for the rewrite when the blame game is targeting someone who can't defend himself.

      There is some confusion here about the issue. The post here seems to be about performance whereas the original article refere

    • 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:

      http://c2.com/cgi/wiki?RulesOfOptimization [c2.com]
      http://schwern.org/~schwern/talks/What_Works/What_Works/slide016.html [schwern.org]
      http://www.cs.cmu.edu/~jch/java/rules.html [cmu.edu]

      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.
  • Given that the linked "comment" is a status message on Twitter, it's most definitely a tweet. No "probably"Âabout it. Half an ounce of logical thinking would have told kdawson that.
  • 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.
    • So, your proof is a rumor that has been immediately denied by the people actually running the site?

      QED! QED! You go man!
      • It's the Life of Brian conclusion. Because the rumor was denied, it must be true!

        "I'm not the Messiah! Will you please listen? I am not the Messiah, do you understand? Honestly!"
        "Only the true Messiah denies His divinity!"
        "What?! Well, what sort of chance does that give me?"
    • by Sancho ( 17056 ) *
      Rails has its place. It's a toy that you can use to build small-scale sites, and it's a tool that can be used for rapid prototyping in preparation for coding with a more appropriate tool. The problem is that people try to build large-scale, production sites using Rails, and they find that it just isn't elegant anymore due to the hacks that you have to do to get it to support large volumes of users.

      Of course, by then, they're committed, both in development time and emotionally to the project. It's hard to
      • by Firehed ( 942385 )
        I think the slew of 37 Signals/BaseCamp stuff is also RoR powered, and I don't remember ever hearing about scalability problems for them. I think the issue with Twitter is that every time someone tweets, a mail message goes out to tens to tens of thousands [twitter.com] of people, and mailservers tend to not really care for that much activity especially when real time messaging is expecting. Architecturally, a tweet is just an INSERT query followed by a SELECT with some not especially complex JOINs - it's just that eve
    • Re:Ruby Can't Scale (Score:4, Informative)

      by ivan256 ( 17499 ) on Friday May 02, 2008 @12:38PM (#23276272)
      They're complaining that the framework can't scale. Not the language.

      Please refrain from commenting when you don't know what you're talking about. The desire to stir up a flamewar is not sufficient justification.
    • Re: (Score:2, Interesting)

      What is it exactly, about the framework/language that makes it difficult to scale? Honestly, I've heard this complaint about RoR for years, but no one I know has enough knowledge to verbalize the issues. Can someone who is knowledgeable in RoR give a few points here?
      • Re: (Score:2, Informative)

        Sure, the problem is that 1) Rails isn't thread safe/no native threads and 2) Ruby processes are very expensive in memory.

        So. Since rails isn't thread safe you have to use a process model where one process handles one request. Now these ruby processes can get up to 100MB in ram (depending on application). That means it takes 100MB to post a comment, display a page,etc.. This is an extremely unforgiving environment when you are trying to scale. There are many scenarios where just a little extra i/o w
  • 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.

    • Yeah, but sometimes engineers blow off something that really is neat and exciting because of their silly, unscientific, emotional views about the way things should work.

      Rails has its share of issues -- deployment is way complex, performance sucks, and the community can be rabid in the same unscientific, emotional ways -- but buggy and unstable? Come now, that's disingenuous.

      When Twitter opened it was handling 11,000 requests per second and doing it well. Twitter has gone from nothing to sensational in a ver
      • Re: (Score:3, Interesting)

        by revscat ( 35618 )

        When Twitter opened it was handling 11,000 requests per second and doing it well. Twitter has gone from nothing to sensational in a very small amount of time. If you hit the ground running that quickly, your growing pains will be evident regardless of what framework or language choice you're using.

        That I'm going to have to disagree with you on. For starters the most recent troubles that have plagued Twitter happened as recently as a few days ago. They have had plenty of time to mature their stack, but th

    • I feel like it's important to note that, most often, "hype" is not "just hype".

      What I mean is, lots of things in life are over-hyped, but the hype usually comes from somewhere. There is something within the over-hyped thing that people are genuinely excited about, impressed with, or desirous of. They may have trouble explaining the true source of their excitement, but if you can find that source of excitement, you'll usually find something worthwhile.

      So although Rails was over-hyped by some people, we m

      • by Shados ( 741919 )
        The hype came from people not realising that Rails offers little to nothing that hasnt been mainstream in the professional world for years before RoR got its name. People unaware of that saw Rails as a revelation. The rest of us yawned.
    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Friday May 02, 2008 @01:56PM (#23277328)
      Comment removed based on user account deletion
  • There is no link to any original statement at all only a link to the response. If it was a twitter was the original statement: "ROR: Fail". :P
  • What will it take to get twitter [slashdot.org] to abandon Slashdot?
  • In related news, twitter (104583) [slashdot.org] reportedly may abandon his use of sock puppets due to numerous outages.
  • The problem is ruby (Score:4, Interesting)

    by mdipierro ( 1163129 ) on Friday May 02, 2008 @12:57PM (#23276560) Homepage
    The problem is Ruby. It is a very slow language (http://www.blognone.com/node/4385). My tests confirm it is 20 times slower than python in simple loops. Java is a dinosaur and PHP is not easy to maintain. I would go with Django or web2py. If they use web2py (http://mdp.cti.depaul.edu), I will help them. web2py scales very well because allows you to bytecode compile the models, the controllers and the views (so there is no parsing when serving a page) and cache every function in ram.
    • by e4g4 ( 533831 )
      The problem is the stock (1.8.x) ruby interpreter. As the language matures, better and better implementations of the interpreters are cropping up, and it seems [antoniocangiano.com] that ruby 2.0 will easily catch up with python in terms of performance. There's nothing wrong with the language - blaming the language for the failure of the interpreter is tantamount to blaming C for the difference between the output of intel compilers vs. gcc.
    • I don't think the problem is Ruby. Whilst I'm not associated with Twitter, I have seen some of their presentations on subject of performance, and the major bottleneck seemed to be the database, and ActiveRecord's unoptimized querying of it.

      MatzRuby 1.8 is somewhat slow, but it does proportionality very little work compared to the MySQL and Memcached back end. Quite frankly, I've never seen a performance profile of a Rails site where Ruby was the problem; it's almost always the database, or too many AR queri
    • Re: (Score:3, Insightful)

      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.

  • Twitter was smart to use Rails to develop their business, and is also smart to move the performance-critical message queueing and posting portions to a higher performance technology when it got big and mature. The evolving parts are best left on Rails.

    Rails remains the best way to develop solid and maintainable web apps. But it will not compete with C for speed. Once you understand your business process, and have developed a mature algorithm to make the business work, there is nothing wrong with writi

  • 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 pseudorand ( 603231 ) on Friday May 02, 2008 @03:25PM (#23278568)
    Pardon the off topic rant (please feel free to mod appropriately), but I have to agree that RoR DOES SUCK. (At least I didn't set up my own blog just to rant about it.) The RUBY language is the best thing since sliced bread, but Rails isn't. And I'm not talking about the installation and management issues like everyone else. I mean from a developer's perspective, RoR is horrible. Here's why:

    1) Automated copy-n-paste is still copy-n-paste
    Maybe it's changed since the last time I used it, but creating a rails application COPIES a bunch of files from the distribution into the app directory it creates. How do you upgrade? Painfully, that's how. I have numerous small applications that break when I upgrade rails and it's dependencies because the copied files don't work with the newer version. My applications should be 100% code I write directly. Everything else should be kept separate and accessed via includes so emerge/apt/yum/gem dependencies can keep the rails code compatible with itself and I never have to "fix" code I didn't write.

    2) RoR gives you the 1% that's used 10% of the time, not the 10% that's used 90% of the time.
    So you set up a RAILS app, create your database table, and run 'generate' to get your pseudo-MVC (seen #4 below). You've got everything you need to edit a single table via the web, but that's not even close to an application. It probably saved me about 1/2 of setting things up by hand. That's simply not good enough. It should be able to create an app that supports validation (both JS and server-side for obvious stuff like numeric and lengths), sorting, filtering, searching, relationships, and css skins. It could do this just from the information available in the database metadata, which would get you 90% done. And a huge number of simple apps could be completed simply by writing a custom CSS skin and adding some graphics.

    3) No UI components, which are the hardest part of web development.
    Most of what rails does buy you is the back-end stuff. It's an easy way to get stared with ActiveRecord, which does the heavy SQL lifting. AR, the one shining gem of RoR, is a great object-relational model and I believe it is responsible for 99% of RoR's popularity. But SQL isn't that complicated in the first place. The real tough part of web development is getting rich, graphical, reusable UI components that work across web browsers. Prototype/Scriptaculous are a wonderful starting place, but I need code that I can feed an AR class (and possibly a list of columns and/or related tables+columns) that will generate cross-browser compatible HTML view of the table complete with searching, sorting, filtering, and paging. There could be functions/objects that render it as a table, a list, a tree, etc. You're probably thinking I should just use .NET and it's various components, but I don't want to work on Windows, I don't want to work with IIS, I don't want to write VB or C#, and .NET really does a bad job of layouts and makes a lot of other stuff more complicated. And it's ORM simply can't touch ActiveRecord. Rails does only a tiny amount of what it could and should.

    4) It's NOT MVC
    The Model-View-Controller design pattern is about limiting the amount of communication necessary by having one instance of some code (the controller) that all access to data (the model) from other code (the views) goes through. Views subscribe to a model, get their data and then do their thing without worrying about other views. If some other view changes the model, the controller notifies all other subscribed views of the change. Rails MVC is something totally different that doesn't solve the same problem. Rails does provide data validation via AR, which is part of true MVC, but it still misses the point of MVC, which is a coherent and always up to date set of views into the model. In fact, an MVC is impossible to implement over the web because communication is one way: the browser must initiate all communication with the web server. (For those that don't "get" this,
  • by LionMage ( 318500 ) on Friday May 02, 2008 @08:16PM (#23281180) Homepage
    I wonder if they've considered Groovy on Grails instead of Java or PHP? Groovy has all the dynamic language features that make Ruby and JavaScript popular with developers, but is essentially 100% backward compatible with Java (since it's running on top of the Java VM and is implemented in Java). Groovy also leverages Java and any other language that can be hosted on the Java VM because it interoperates with all of that stuff, and itself runs on the same VM. You also get legitimate closures and simplified syntax for many things. It can even give you Java 5 semantics (generics, enumerations, etc.) under JDK 1.4.

    Grails is very similar to Rails, but is not a straight port -- more "inspired by," as it's described by its proponents. Grails also doesn't have the problem that Rails has in terms of scalability and performance, since it's built on Groovy/Java (which have a real threading model). No screwing around with creating a zillion Mongrel instances to scale your site, etc. And if you don't care to use the built-in web server that comes with Grails, you can have the Grails framework generate a WAR file which you can deploy in any container like Tomcat or Jboss.

    At a recent 3-day Grails training session taught by Scott Davis, I was surprised to hear that some major corporations have jumped on the Groovy/Grails bandwagon, including Mutual of Omaha. For a conservative company to make that kind of leap says something. (Furthermore, they used to be a COBOL shop -- the rationale appears to be that it's easier to get COBOL programmers to make the leap to Groovy first, then switch slowly to Java, as opposed to migrating directly to Java.)

    After that 3-day training, I was pretty impressed. The biggest win for Grails seems to be rapid development and deployment, but all the other stuff you get for free in the package makes it something you'd like to stick with. I'd say the thing that most impressed me with Grails was GORM, which makes Hibernate even easier to work with. GORM spoils me, since it obviates the need to write SQL most of the time.

For God's sake, stop researching for a while and begin to think!

Working...