Thinking about Rails? Think Again 482
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."
Re:article: -1, troll (Score:3, Informative)
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.
(I'm the author of the article) - Please read: (Score:5, Informative)
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.
Re:Misleading summary (Score:2, Informative)
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:
With the amount of PHP FUD we see on
Re:Misleading summary (Score:3, Informative)
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.
Re:thinking about something new? think again (Score:3, Informative)
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]
Re:thinking about something new? think again (Score:4, Informative)
Re:Why rewrite existing systems? (Score:4, Informative)
Ruby is nice, Rails has some severe limitations on what it can do without major hacks.
Examples:
Business Model versus Business RulesThere 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.
Re:7) How far will it scale (Score:3, Informative)
* 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.
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...
Re:Why rewrite existing systems? (Score:3, Informative)
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.