Forgot your password?
typodupeerror
Programming IT Technology

Thinking about Rails? Think Again 482

Posted by CmdrTaco
from the or-not-at-all dept.
wolfeon writes "In 2005, Derek Sivers of CD Baby wanted to scrap his site and perform a rewrite in Rails. He hired Jeremy Kemper, also known as bitsweat on Freenode, to help on the project. Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project. Mr. Sivers has written an entry in the O'Reilly blog: 7 reasons I switched back to PHP."
This discussion has been archived. No new comments can be posted.

Thinking about Rails? Think Again

Comments Filter:
  • by z_gringo (452163) <z_gringo@hotmEIN ... minus physicist> on Sunday September 23, 2007 @09:50AM (#20718717)
    He actually says the exact opposite of most of your points.

    He had one of the best rails programmers there was. It wasn't a problem with not knowing rails. He still wasn't finished after 2 years. He could accomplish the same thing faster in PHP.

    He specifically said that using and learning Rails helped him change his thought process for the better.

  • by linuxbaby (124641) * on Sunday September 23, 2007 @10:23AM (#20718897)
    Hey gang -

    Longtime Slashdot reader, surprised to find my little personal blog post on Slashdot today, especially since the lead-in description framed it with the completely wrong point.

    I never said "the project was cancelled because of limitations of Rails" - more like I spent two years trying to make Rails do something it wasn't meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

    That's all.

  • by chdig (1050302) on Sunday September 23, 2007 @10:57AM (#20719137)
    He appreciated Ruby, brought back some programming concepts to PHP, and used them. The concepts and clear flow of programming in Ruby are great, emphasizing MVC and separation of code, and can be used in PHP too (which is something most people for some reason think isn't possible).

    This article is interesting (and more than just fanboi talk) because it dispels some key myths about both Ruby and PHP -- all 7 points fall into two categories:
    a) PHP can do it just as well or better.
    b) PHP doesn't force the programmer into one way of programming -- rather, he can do things his own way (use SQL statements, program the way he likes).

    I find his point 5 is the key here, and why many of us love our PHP:

    I don't need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn't complain.
    PHP exposes more of the guts of the language to the programmer. It's easier to make messy code, to leave security vulnerabilities, to have duplication, and to be inefficient in coding. But while this is true, it's also the kind of FUD that this article tackles. The author even wrote that he believed PHP was a bad language for years before returning to it, employing good programming concepts and realizing that it was the most powerful option available.

    With the amount of PHP FUD we see on /., it's nice to see a counterpoint
  • by vidarh (309115) <vidar@hokstad.com> on Sunday September 23, 2007 @11:31AM (#20719393) Homepage Journal
    PHP is a bad language. It's a nasty mess, though it's gotten better with 5. What it has is simplicity, speed for web apps (compared to the current Ruby interpreter, and largely because the PHP interpreter is nicely integrated into Apache - this is not an inherent advantage of the language, but an implementation issue) and a huge number of built in, fast C extensions.

    I've picked PHP for web apps too, though I much prefer Ruby as a language (not too thrilled about Rails, mostly because I have an allergy to frameworks - I much prefer picking components based on my needs).

    What you say is right - it's far easier to fuck up in PHP than with Rails (but you can equally easily fuck up if you use Ruby alone), but one of my biggest problems with relying on Ruby for web apps right now is scalability. Yes, I know you can scale Rails, but the number of hoops you have to run through to get a Ruby based (regardless of Rails) application to scale is a hassle, and negate a lot of the things that make Ruby a great language for other things.

    The threading model in Ruby, for example, is completely fucked up and kills performance if you need to do many threads and a lot of IO at the same time. It also makes things like failover harder whenever you have to depend on badly behaved C libraries (the MySQL client library is a pet hate of mine, since it can lock indefinitely in connect() for example, making you jump through hoops if you want to use it safely in a multithreaded Ruby app without risk of stalling).

    Hopefully that gets taken care of in a future version, but it's a problem right now, and it's a larger problem because the interpreter isn't fully reentrant, making it harder to embed it and scale it with multiple threads outside the interpreter.

    It doesn't stop me using Ruby, or recommending Ruby, but a lot of the Rails fanboys shoot themselves in the foot by ignoring the problems. They'd do Rails (and Ruby) a lot more favors by being honest about what's hard so people know what they go to. Problem is, not many of them actually know what's hard to do with Ruby, because few sites get the kind of traffic that will start making scaling further hard work.

    It's hard work at various points with other languages and frameworks too, but the pain points are different, and what people are used to do with PHP is quite different from what they need to do to scale Ruby.

  • by Anonymous Coward on Sunday September 23, 2007 @12:28PM (#20719863)
    I'd just like to point out that the parent is decieving. He's not a programmer. According to his website, "Bill is employed by Century College working on developing new recruitment and retention programs." I seriously doubt that means programs in the slashdot sense.

    He's just pissing in the GP poster's cornflakes; he isn't for real and should be modded appropriately. His only technical qualifications seem to be messing with his own blog, which he describes as "working on the website."

    Don't take my word for it though -- follow the links and decide for yourself how technical Bill might be. I personally have formed the opinion that he's a cereal-pisser.

    Here's his own list of articles with a more technical bent:

    http://www.lazylightning.org/taxonomy/term/6 [lazylightning.org]

  • by TheRaven64 (641858) on Sunday September 23, 2007 @02:21PM (#20720749) Journal

    * a rich standard library with a good reference
    Common Lisp probably wins here. The Common Lisp spec is a weighty tome filled with small writing. Smalltalk doesn't really have much of a standard library, but the most popular implementations have quite large ones. If I can add Objective-C to the list, OpenStep is pretty close to a standard library for Objective-C and is a joy to use.

    * a good extended library like CPAN
    Hard to answer without understanding what it is you like about CPAN. There are a huge number of Common Lisp libraries around (from FastCGI to OpenGL bindings). Squeak (Smalltalk) has its own system for distributing third party libraries. Not sure about Haskell and OCaml. There is a huge amount of Objective-C code out there too, although a fair bit of it is Apple-only.

    * easy extension in C
    This is where Objective-C totally wins over everything else, since it's a pure superset of C. There is a standard mechanism for calling C from Lisp code, so it's fairly easy. Calling C from Smalltalk depends on the Smalltalk you use; it's hard in Squeak, but pretty easy with GNU Smalltalk. Not sure about Haskell and OCaml.

    * good documentation
    Lisp has a huge amount of documentation. Smalltalk does, but it tends to be specific to a given implementation (although modern Smalltalk tends to be a superset of Smalltalk80, so the older the documentation, the more likely it is to be applicable).

    * easily available compiler, etc.
    There are a few Smalltalk implementations around. The popular free one is Squeak, which is close to the original Smalltalk. There is also GNU Smalltalk, which is file-based, and so closer conceptually to other languages. For Common Lisp there are lots of compilers, but the best Free one is Steel-Bank Common Lisp (sbcl). There are a few Haskell implementations available. The one I learned on was HUGS, but I think GHC is more popular. For OCaml, I've honestly no idea. For Objective-C, the only compiler anyone really uses is GCC (although, no doubt the author of POC will no pounce on me and tell me he and at least one other person use it).
  • by tacocat (527354) <tallison1@@@twmi...rr...com> on Sunday September 23, 2007 @02:57PM (#20721043)

    Ruby is nice, Rails has some severe limitations on what it can do without major hacks.

    Examples:

    Business Model versus Business Rules

    There is a distinction between the Rules and the Model. Rules are those things that must be enforced against the data. Examples of this would be (in database terms) referential integrity, unique values for certain fields or combination of fields.

    Without this distinction you can easily run into rampant data duplication and your ability to determine what is actually going on becomes a major challenge. Rails fails on this enforcement of the rule because when you identify something as being unique according to Rails, it's managed by a Model declaration to check for uniqueness before making an UPDATE/INSERT SQL execution. Problem with this is you are assuming that you have only one active rails session at a time. If you don't, then it's trivial for two web sessions to insert the same username in the table, thereby fucking your database and your business. Without the database actually enforcing the data through database constraints, you cannot guarantee the results.

    Things get even more difficult/tricky when you have to ensure that combinations of fields remain unique or referential constraints are preserved.

    I'm know there is some way to do all of this in Rails, but it's counter productive and essentially a hack. For example -- I would have to create additional unique SQL constraints in the database migration files, in some cases, I have to write out the SQL directly -- bypassing that which is Rails. Then the Model would not only have to run the extraneous SQL statement to check for uniqueness, but also be modified to accomodate the error handling that is going to happen when you violate the database integrity. Again, this makes for a lot of non-Rails and non-elegant code.

    Don't get me wrong, Rails is nice but it is not really going to be a useful product for some major site that is going to just get crushed in transactions. Do you really think you can open the next MySpace and have it keep all the data properly synchronized? I know it's possible to get around the application rules of the Model, so I know it's also likely to muck up your data.

  • by mcrbids (148650) on Sunday September 23, 2007 @04:35PM (#20721755) Journal

    After 30 years development, "How far will it scale" is

            * the question that scares me most,
            * the one that you can never get honest information about from OS or component suppliers,
            * and the one that's hardest to test because the most-used features are rarely those you expected.
    After my 10 years of development, "How far will it scale" is
    • the question that scares me most,
    • based only on an honest assessment of how I structure the software, and
    • utterly irrelevant to OS or component suppliers


    Seriously - if you want to scale, you need to avoid the Shlemiel the painter's algorithm. [joelonsoftware.com] Avoid this sucker with passion and verve. Hunt for ANY CASE where this algorithm is hard at work, sucking away CPU cycles endlessly towards the abyss of swapped memory, session timeouts, and database deadlocks. When you've learned to look for it, you'll be amazed at just how rampant this nasty little bugger actually is.

    I wish there was something more to it than that, but I've seen time, and time, and time again, lousy performance made snappy simply by finding and refactoring code that uses this kind of algorithm. Simply put, it's code that processes each bit of data slower as you add more total information to process.

    And that's where PHP shines incredibly bright. For as much as you'd hate to admit it, Java's server "shared" VM is a variation of the dreaded painter's algorithm, as is any other form of "shared environment". PHP shares nothing. Each hit is unique, and the only thing that's shared are a few session variables. So, if you structure your application right, you can have 100 servers all serving your PHP application, no matter how computationally dense it is.

    And that, brother, is the key to real scalability - Knowing that you can add performance in a linear fashion as the amount of information processed grows. If load climbs faster than the amount of information being processed, hunt the painter! He's in there somewhere...
  • by jadavis (473492) on Sunday September 23, 2007 @06:02PM (#20722347)
    Examples of this would be (in database terms) referential integrity, unique values for certain fields or combination of fields.

    I agree completely.

    More generally, ActiveRecord does not address any interdependence of the tuples or relations at all (except for a few very common cases where they have no alternative).

    ActiveRecord is essentially a persistence engine at its core, with it's own OODBMS-like API on top (that is not closed over any useful set of operations). It blindly assumes that objects are independent of eachother, and can be created, updated, or deleted without regard to the rest of the data. There are some special cases that are addressed, but they are far from complete. In general, ActiveRecord does not even know how to handle database errors, even though the SQLSTATE error codes are defined in the SQL standard. It doesn't expect errors aside from the few special cases.

    It has no regard at all for potential race conditions with another application accessing the same data. In fact, it assumes that it's the only application accessing the data, and the data therefore really has no meaning outside of the context of the ActiveRecord application.

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord

Working...