See also:
Aliases: Rails / Should you adopt it?, Rails / Evaluation, Rails / Analysis of, Rails / Compared with other web application frameworks
Contents |
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30:
Testing in integrated frameworks, Part 1
Migrating to Ruby on Rails and PostgreSQL: An Interview with CD Baby, 2005-11-02
Ruby on Rails: An Interview with David Heinemeier Hansson, 2005-08-30
http://www.thoughtworks.com/ruby.html
Tomas Jogin on September 27 (http://www.loudthinking.com/arc/000516.html):
http://developers.slashdot.org/article.pl?sid=08/01/10/214219&tid=156.
... Listen, folks, Rails is the right answer some of the time and it's the wrong answer some of the time. Just like any language. SQL, Javascript, PHP, Rails, C, Java: they all have things they are good at and things they are bad at. The author at least gets that part right, but then goes on to undermine it repeatedly. At the end of the day, articles like this only encourage the detractors and scare away the uninformed.
5. Rails is extremely flexible
I'm a Rails developer, and I have to say I disagree with this. When you work within Rail's comfort zone, it's a joy to develop in. But start to edge outside those boundaries, and suddenly everything starts to fall apart. A lot of things that could be made modular are currently hard coded, especially in the monolithic and huge ActiveRecord. Rails is designed to work well given certain conditions, but try to do anything clever or unusual, and it's a toss up whether you'll get away with it without running into problems.
Rails may be a nice framework, but flexible it ain't.
I'd never used RoR or even Ruby, but I was hearing a lot about it and I had a hobby project that I wanted to start on, so I bought an RoR book, and spent HOURS working on it. Then I gave up, having accomplished nothing, switched to Django (mind you, I'd never used Python before, either) and started getting stuff done. (Well, a more full story is: I started with Ruby, switched to Django, realized my host doesn't support it, tried Ruby again [now I understood the framework better, from using Django, but the language still looked like Swahili], then moved to CakePHP which IS supported by my host, realized how much easier and less-fussy Django was, decided "to hell with my host, I'll get a new one if I ever decide to take this code live" and finally went with that.) My hang up with RoR is the Ruby part. It's completely unreadable to me. Python, I could understand reasonably well before I even started reading any "learn Pythong" material. Same with most other languages. Any Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me. However! My first language was Perl. People often complain about how hard it is to read, and I instinctively bristle a bit when they do, because to me, it's the easiest language to read. The reason? Perl code tells a skilled Perl coder TONS about what it's doing and how, but confuses newbies like crazy. Ruby strikes me as being much the same way. So, I understand why people who have taken the time to really learn it enjoy it so much, but for me it's so much easier to choose a framework that uses a "pick up and go" language like Python and be done with it. It does the same stuff, and I can get right to learning and working with the framework rather than dicking around with the underlying language. I'm really not trying to pick on the RoR people, nor being petty (really!). I know it's a good framework, and I know that if I took the time to learn it I would like it just fine. Just getting a perspective out there that's not "rah rah, RoR is the best thing ever!" or "boo, RoR ran over my puppy!"
A lot of Ruby tutorials do try to be overly clever. But really, quite a bit of C code was/is overly clever, also. People cramming so much stuff onto a single line that the code is unreadable and difficult to support. But that's not really a problem in the language. That's a style thing. I very frequently when coding in C, Java, or C# split things onto multiple lines that could be expressed in a single line. I often take intermediate values and put them into variables with good names, instead of ramming the values all together. I remember when I was a wee lad, learning C, and being utterly baffled by a lot of the code I read. Casting pointers to other things, doing math, switching to array notation, then suddenly treating the whole expression as a function pointer, and feeding a stream of other things as arguments into the function... That kind of thing is amusing, but has no place in typical production applications code. Something far more common is huge expressions with the ternary operator that are just one element in a more complex expression. I saw this kind of thing in most of the C code I read, and felt like I must be a noob if I didn't do that. Then one day I decided I just would write code that was simple and made sense, and that's what I do-- it's a style choice. The point is, writing code that's easy to understand is up to the programmer, and less to the language. People used to defend COBOL because it was more readable. But one huge problem with COBOL is you've gotta write a lot of lines of drivel to get anything done, compared to say C. The price we pay for the comparative expressiveness of C is we have to be more careful with the code to keep it understandable. From C to Ruby is a similar jump in expressiveness, with a commensurate risk of it being less understandable. But it's possible to write difficult to understand code in any language. Ruby does have some things in it that make it quite different from other languages, most notably closures and metaprogramming. But honest, you do get used to it. You can even avoid the elements you're not comfortable with, and ease into them later. But over time you start to find there's quick and dirty ways of doing things in very few lines of code in Ruby. And things like testing kits and the way Rails helps you structure your code make it so that your code is spread out nicely, and it's easy to isolate bugs quickly, even if some of your code is a little overly terse. I recommend not starting with Rails. Spend a few hours alone with Ruby before trying to wrap your head around the way Rails works. Write a tic tac toe program on the console, or something. Get to where you've made peace with Ruby before you get into rails. Because starting off directly with Rails and Ruby, not understanding either one can be very difficult. They are both such different approaches from what many developers are used to that it's a bit like learning Pig Latin and Chinese at the same time.
Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me. Ruby looked like gibberish to me, too. Coming from ARexx (heh) and PHP, with a bit of C etc, seeing: %w{foo bar}.map {|e| e.upcase } Simply didn't mean anything to me; map? What are those {}'s doing? What's |e|? What the fuck's %w{}?! It's bit of a triple-whammy really; first you've got a bit of perlish shorthand (%w{foo bar} == ['foo', 'bar']; make an array containing these words), second you've got a code block with slightly Smalltalkish parameter syntax, and third you've got an unfamiliar verb "map". But you're right, once you actually grasp some of the concepts (and if you don't know about things like map/select/reject/inject (reduce), you really fucking should, I don't care what language you use) and the basics of the syntax, it all just flows; make an array, make a new array from it by running the upcase method on each element, just like: array_map('strtoupper', array('foo','bar')); Only it doesn't fall to bits when you want to do non-trivial things to the elements. After that, it's mostly getting familiar with what the other methods do and getting used to using/chaining them. If it doesn't go from confusing to obvious or even useful outside Ruby in an hour or two, you're probably doing it wrong. Similarly when it comes to things like metaprogramming; it starts off confusing and ends up being a force multiplier for your work. The confusion hopefully means you're learning something new, and you don't become a better programmer by running away from that.
Ruby and Rails are delicious, but there's 2 things I need that I can't get from Ruby on Rails right now. Because of these 2 things, I am using C# under Mono, but I'd far rather use Ruby on Rails if I could: 1. Protect the code. I need to be able to deploy it without the code being easily copied and reviewed. I know, I've seen it all on this topic: I don't really need to protect it, whatever I'm doing isn't that hard to figure out, etc. Trust me, I really need to protect the code. I write products for a living, and my customers will unfairly pirate/sell/give my code away, and it will cut into my income if I can't keep control of who gets my code. This is why I'm using C# and Mono. And yes, I realize that can easily be decompiled. But it's still more than adequate protection in my business space. 2. Make it faster. Ruby is too slow for what I need to do. My customers can only afford around $100 USD/mo for hosting my special purpose application, and for the number of people they get hitting the site, Ruby doesn't cut it. I know, I know, do more caching do more magic, get more computers, build a server farm, etc. Whatever. I just rewrote the thing in C# and I could support way more users per $100 of server. It made me cry to have to do it. Please, if there's ways to do better on those 2 areas, let me know! But trust me, I really do need to protect the code. I'm thinking I might be able to solve both of these problems using JRuby some day, but I'm not sure yet.
[Software development / Practices and philosophy (category)] [Well-written (category)] That's a good measure for those who have no intention of developing with the technology. However when I evaluate something's technical merits, I actually try to make something with it. If it handles certain tasks better than other methods I know, it's useful. If it assumes too much about how I'm supposed to use it, its much less useful. Not being thread-safe, not having both blocking and non-blocking versions of certain API calls, etc are all points against a product. I also grade on elegance of design. There's an old saying, what do you get when you mix 100 gallons of ice cream and a teaspoon of shit. 100 gallons of shit. If the layer below the one you're writing is poorly designed, the design flaws will invariably propagate upward. One last point about these "easy to use" frameworks geared towards the average folk. The more complex details you hide trying to make it simple to use, the easier it becomes to use it wrong unknowingly. There is no silver bullet to get around algorithm efficiency, and a properly ingrained understanding of how computers solve problems and how to classify various problem types. Teaching someone to use an over-powered IDE and giving them a certificate which says that they know how to make programs that run, is no assurance that those programs will run well. The author of the opinion piece said Rails helps smart people write a certain type of program faster. That is an arrogant statement, there are plenty of smart people without the formal training the author has had which probably use Rails poorly. It would have been more accurate to say, "Rails helps people who think a certain way accomplish a limited subset of tasks faster." The more I read, the more both sides of this drama sound like elitist pricks, which can be an epidemic among web communities. Some very smart people over compensate for not having been popular in High School and create exclusive online communities rather than inclusive ones, these people tend to handle any criticism very poorly. Of course these people get worn down by people demanding so much from them without ever offering any compensation for their time. If you want a good measure of what sort of people are in a given community, go to their IRC channel and ask a question from their FAQ. (Disclaimer: not a web developer, never used Rails, no plans to in the near future)
There's 3 aspects to the slowness, IMHO: 1. The language. Ruby tends to be slower. Something like this programming language shootout [dada.perl.it] will give you details. But this isn't the whole story. 2. Enough rope to hang you. Rails gives you a lot of ways to easily define dynamic classes, where the class is being generated dynamically on the fly. It can make the code lovely and small to use, but can make it slower than hammering it out in a lower level language. This and other techniques can lead to higher memory consumption, too. But I don't fault the language here. I see it as a powerful tool that must be wielded carefully sometimes. 3. Active record. A lot of the slowness that people see can come from automagic that's happening in the background. If you're not careful with active record, for example, it pulls in every last field from table you're looking for, along with the relatives. I just needed the customer's name, and ended up with 8 kilobytes of data because I wasn't careful with what I was doing.
ActiveRecord - Achilles Heel of Ruby on Rails?
Christopher Petrilli voices his concerns in this article: Least Common Denominator, 2005-09-27
http://www.techcrunch.com/2008/01/01/zed-shaw-puts-the-smack-down-on-the-rails-community/.
Wow, you don’t see rants like this every day. Zed Shaw, who created Mongrel, a library and web server that just about everyone uses to serve rails applications, is basically a God in the Rails community. In a post today called “Rails Is A Ghetto” he tears into a number of leading Rails developers, the community in general, and a number of startups (and Google). The post is long but highly entertaining, even to those of us outside of the core community. Basically, Zed just started a shitstorm that is going to reverberate through that community for months. Most entertaining quote: “This is exactly what makes Rails a ghetto. A bunch of half-trained former PHP morons who never bother to sit down and really learn the computer science they were too good to study in college.” ... And (last one): “With Rails I get scrawny cock suckers with carpal tunnel syndrome talking to me like they’re gonna eat my young. Their feeble PHP infected minds can’t grasp advanced shit like objects or closures. When you combine stupid businesses with stupid people using a stupid framework based on a big fat fucking lie on a shitty platform you get the perfect storm of dumbfuck where a man like me can’t find work.”
I got tipped to this rant on twitter and had already read it when I saw your post here. As I said earlier (on twitter), “…Bitterness of the tone aside, are his points valid / verifiable? Dunno… yet”. The point he makes about performance & stability is probably the most important. Again, gotta read around the angry style, but R (and RoR) is pretty damn flaky WRT performance & stability. I wrote a little about this back in November, and will simply quote myself here in reference to all the downtime at Twitter (p.s. I like Twitter): “I think Ruby’s edges (or core maybe) are showing here. This has been discussed at length at Laughing Meme, but I haven’t seen much about this subject on Twitter’s blog. Lots of folks are using Ruby daily, with many of them adopting Rails, and all of them have a stake in its future. Performance is a tough characteristic to engineer into a language (or even a project) after the fact. Is Ruby/Rails going to be able to pull this off, or will it remain “…dead slow” to the point of no longer being considered for scalable web development?” Again, dunno.
Zed has nailed it. One applauds the enthusiasm of those discovering the limits of their talents in coding. Usually, that means they are coding up a shit storm. Rarely does it mean they are ‘coding up’ a successful company. Jumping to the successful business isn’t always what one does. You can code without design, you can design with a plan, and you can plan without business concept, you can conceptualize a business without experience. If you want to succeed ($$) do some that is based on the public’s general laziness (and not yours). The wider the def of ‘public’ is, the more money you make. Facebook makes it easy (lazy) to meet people. What is ‘ease of use’? Its *hard* to make it easy. Nice Zed! Nice pick Techcrunch!
Honestly, I like Rails, but Rails community truly sucks. It’s full of dead and unmaintained projects such as Active Merchant, Typo, Mephisto, and a bunch of others. RubyGems is getting released without basic testing on major platforms like Windows and so on. A change is definitely necessary!
Most places want Java and/or PHP experience. As popular as Ruby & Ruby on Rails are to people in the “know,” they’re still relatively unpopular. Ruby is less esoteric than Lisp & ML, but not very much…so a Rubyist should expect about as much success finding an amenable job position as a hardcore Lisper/MLer
I have always had this view of the Rails community - but thats what happens when you design a software development platform to be easier to use - you’re going to get a noobish tinge to your community.
Wow..it’s great for someone to actually step up and say what a farce Rails is. Does anyone know of any serious website that actually uses Rails…Basecamp? you kidding…Sharepoint is more impressive as an app. I spent a year basically killing my career as well trying to get a Rails app running because our investor thought it was so hot. Holy shit…a complete disaster. If anyone has _real_ successes…then chime in. I want to hear “Dude, I made $5M on my Rails webapp…we produced code 10x faster than everyone else and made a mint” Instead I hear the general “Hey I can do Hello World in ten lines of code”. the problem is simple: 1) No compiler - this means that you get to remember everything in your head…change this, break that….lots of fun when you have customers down 2) Crap threading - this has all the problems that a web app without threading brings 3) Crap performance - not only is Ruby slow…but you have to improve performance with caching….for God’s sake wtf wants to cache dynamic content..why can’t stuff just work. 4) Nightmare to manage - This is the worst….its like working on live electricity all the time…its terrifying to deploy new code because how much testing can a startup really do.
Daniel F. Savarese (2007-03). Rails: A Development Gem: Ruby on Rails speeds development with Oracle Database. (http://www.oracle.com/technology/oramag/oracle/07-mar/o27rails.html).
Ruby on Rails (Rails, for short)—one of the more popular alternatives that has emerged in recent years—offers the most commonly used functionality of Java Web application frameworks, but with less complexity. Rails shines where rapid development takes a higher priority than distributed transaction management, application monitoring, and all the bells and whistles Java EE provides for mission-critical application development.
7 reasons I switched back to PHP after 2 years on Rails (http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html).
1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.” For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap. I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be [darned]. But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much. Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed. Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so. 2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system. Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training. 3 - DON’T WANT WHAT I DON’T NEED I admire [...] the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it. With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable. 4 - IT’S SMALL AND FAST One little 2U LAMP server is serving up a ton of cdbaby.com traffic [really] fast with hardly any load. 5 - IT’S BUILT TO MY TASTES 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. I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database. My new code was made just for me. The most efficient possible code to work with our exact needs. 6 - I LOVE SQL Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me. ...
Rails vs. PHP: MVC or view-centric? (http://www.megginson.com/blogs/quoderat/2005/06/11/rails-vs-php-mvc-or-view-centric/).
... [...] the two are drastically different: PHP encourages a page-oriented architecture and makes you do a lot of extra work to get any kind of model-view-controller (MVC) setup; Rails enforces an MVC architecture with pre-defined naming conventions for database tables, etc., and makes you do a lot of extra work to design your application any other way. I’ve long been an MVC and Java servlet fan. I love object-oriented programming, use REST as a web architectural style, and tend to think of XML-encoded data in entity-relationship terms. So why did I like PHP so much better than Rails? I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type. The most common way to generate these views is through SQL queries joining together different tables, and the columns in the result set define the properties of the new object type. I’ve spent a lot of time trying to use and trying to write object persistence layers for web applications, but they never made sense — my models always progressed quickly through the simple CRUD steps (X.create, X.read, X.update, X.delete) but then fell apart as soon as I tried to make my app do anything other than manage its base data. Should I define a new Java class for every possible kind of query result? How do I handle results that do not involve full objects? If I’m not getting full objects in query results, what’s the point of a persistence layer in the first place? After all that soul-searching, prototyping an app in PHP was like a cool breeze on a hot day. I wrote a few helper functions to automate escaping values to avoid SQL or HTML insertion attacks, but I managed to fight off the temptation to write a persistence layer in PHP. Instead, each page has some PHP code at the top that makes one or more SQL queries, followed by HTML markup with only minimal PHP added to insert dynamic results. It works, it actually seems scalable and maintainable, it’s easy to deploy (just about all ISPs already support PHP, so you just upload the *.php files), and debugging is trivial, because the query is right there on the page with the HTML that will display its results. Bugs are not buried deep beneath 20 layers of abstraction, and the database and filesystem are the only shared state. Rails, on the other hand, was a disappointment. It tries to make my database invisible so that I think I’m dealing only with objects, but my database, and its query capabilities, are what will make my application more than just a collection of objects with a simple search box. I ran into a bug during one of the tutorials and it was almost impossible to trace the problem due to the deep layering. And the only thing that Rails seems to simplify is the basic CRUD operations, which are the easiest part of any web app. Rails also tries to tell me exactly how to set up my database and page hierarchy — I know that I can change it, but by the time I’ve learned to do that, would Rails still be any easier? I don’t know if I’m ready to jump to PHP for serious development yet. [...] At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.
Of course, it’s totally possible that the framework is just not for you, but to me, Rails’ architecture actually makes me more likely to think in terms of “how should this view really work, ignoring how I’ll have to implement it.” because there is so much less friction doing something like user.neighbors.magic_data rather than writing a bunch more
$query = “SELECT *…” $result = mysql_query($query)… while ($line=…
At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.
I hear ya. I’m over in Perl-land, but there too, all abstraction layers have failed to really let me use a database as much more than an object persistence layer. SQL is a powerful way to combine and recombine data; all the persistence layers I’ve tried simply force me to clumsily reimplement the work the database can already do for me, and do so much better than anything I can write in the time willing to [spend] on it.
Wouldn’t a better comparison be PHP vs. Ruby or maybe Blue Shoes vs. Ruby on Rails? Comparing a scripting language to an application framework doesn’t seem like the best way to go.
I have to agree with Keith. You are comparing apples and oranges. It’s like comparing PHP with Strus + Tapestry + Hibernate. Which one would you say it’s easier? Still, you would have to admit that Rails is a lot easier that such a Java combo. Personally I make a living developing in PHP and have used different MVC PHP frameworks (and built my own) and now I’m starting to use Rails. I’m making my company switch to Rails for some large projects and I’m not looking back. Good luck with straight PHP.
Its not a question of objects *or* views, the real answer is both. Rails provides that balance very nicely.
PHP vs rails might be apple to oranges, but In my own experience there is much more than a grain of truth in the concept that most MVC/application frameworks are (1) not really needed in building 99% of web apps, and (2) tend to be more complex than the problem they aim to solve. Separating SQL from html is usually a best practice that will give you 80% of code reusability and maintainability. SQL-to-object layers will usually be: (1) - harder to debug: is the local cache copy of the data in sync with the db? (2) - slow: you are giving away the best features your DBMs gives you. You are usually better off writing a stored proc than a query anyway. And what about objects that map to n tables? You will have to write views first, that map into objects. (3) - much less widely known and accepted than plain SQL. Next coder in the project is likely to have had sql experience, not necessarily experience with db-abstraction-layer-of-the-month Templating languages are nice, but things get complicated very quickly as they evolve into full fledged languages (see Smarty for a behemoth). In the end a simple language is a better bet than a good framework!
I had many of the same concerns with Ruby on Rails - until I moved passed the prototype and started developing real applications with the framework. The #1 reason I’ll never code in PHP again (and try get out of J2EE) is that RoR makes it easy to do things the right way. I reuse far more code and I find it drastically easier to track down bugs, conduct unit tests, use continuous integration, and refactor. These are things you won’t experience in a weekend prototype - they are brought to light when you deliver an easily expandable, well-tested, and working application to clients.
PHP fanboys are failing to see a very important distinction here - Rails is for building scalable web *apps*, not for building a quick data-driven website. My own site is 100% PHP, and I will not likely change that. My newest project, however, will be in Rails, because it’s simply far easier to build an object-based web application in a framework like Rails, than coding in PHP. I should know, this is my 5th attempt at building this project. I’ve tried Perl and PHP, and am finding that 2 months of rails work is already surpassing 3 months of PHP work, and the system is far easier to debug and extend. Making the database invisible shouldn’t cost speed. Rails creates the SQL and you can view it all in the logs to see what’s going on. I’m not going to claim the SQL is as good as if I had hand-written it, but it’s not something I’m concerned about causing speed issues. The backend seems to be pretty well-written, and continues to improve. Another consideration is that all RAD tools come with a cost in speed. VB is a language I despise, but I can’t deny that people with vision have been able to throw together an app in a short time, and provide a valuable and useful product that fills a hole somewhere. At my previous job, we originally aimed for Visual C++, scoffing at our competitor who used VB. The competitor constantly outdid us, building new features faster (and with more stability) until we switched to Delphi. What was my point… oh yes, speed tradeoffs. In most cases, if you use a RAD tool properly, you’ll lose a small bit of performance and cut down the development cycle drastically. For most web apps, the query performance isn’t the problem - it’s the bandwidth. And with rails’ architecture, using proper page/action/fragment caching is a breeze, so you can optimize *later* if you need to, without any code redesign. Final thought: don’t rag on rails if you don’t spend a good deal of time playing with it. It may claim to be easy to learn (and it is, mostly), but there are things that make a lot of PHP/Java/Perl people change their minds when they dig deeper than the first layer. It’s really easy to use non-traditional database table and field names if that’s what you want to do, or if you’re connecting to a legacy database, for instance. Many-to-many relationships are expressed so easily it’s almost criminal. Hierarchical data structures, which are usually a pain to implement in a relational database, are a breeze. AJAX functionality, as of 0.13.1, is extremely powerful and still easy to use. Dig deeper; you may be surprised at what Rails can do.
The problem here stems from the incorrect definition of what a web application is — it is not about views, nor is it about objects. A typical web application is centered around the state. The MVC metaphor (or pattern) is solely concerned with the state as well. This is why it is a very natural fit for the web application paradigm. As the user/community interacts with a particular web app, it changes its state. That change governs how is the web app going to behave, which in turn facilitates various behavior from the end-user/community. All these changes in state need to be detected/processed/communicated by the web app. Rails is by far the most sophisticated platform for enabling developers to articulate the above described dynamics. Placed next to Rails, J2EE and/or .NET platforms look like a very elaborate simultaneous translation session during a rock concert for the hearing impaired. Yes, it is possible to ’sort of/kind’ of communicate in real time what’s going on at the concert stage using the sign language, but the real thing is to actually plug in and experience the performance directly.
... My system is homegrown so it isn’t anywhere near as configurable as some of the open source models. But you’re comparing Rails to the absolute worst way of coding within PHP. Only newbies program in php by shoving php code (and sql commands! Ugh!) in the middle of an html page.
I’m sorry but this article is very irresponsible. You played with the two languages for a couple days and then you write an apple-to-oranges comparison with nothing more than a cursory first impression. First of all, you haven’t spent enough time building PHP apps to realize that you end up doing a ton of repetitive work. Sure it feels faster than the ever-verbose J2EE, but combine a dynamic language like PHP with a good MVC framework and you’ll triple your productivity again. As for Rails, you claim that it tries to hide the database, is difficult to debug, and only helps with CRUD. You are wrong on all counts. First of all, RoR is very careful to give you hooks to any level of abstraction you want, from the common find and find_all queries through custom joins and where clauses, down to raw SQL. Why is this better than raw SQL? Because 90% of queries are the simple ones. Just because you are familiar with SQL doesn’t mean a simpler syntax isn’t better. As for debugging, Rails is slightly weaker than PHP in terms of raw print lining, but it excels with features such as the breakpointer and logger. Not to mention you can debug the model completely separately from the command line. The ruby console allows you to modify instances of objects, not only changing methods, but modifying and creating singleton methods on the fly. This opens up debugging doors that users of almost any other language can only dream of. Debugging rails is actually pretty easy, but of course it will be hard when you are a complete beginner to ruby and rails. The whole CRUD thing is a typical argument by people who make a snap judgement after watching the 15-minute video. Scaffold is not even 1% of Rails. It’s practically an afterthought. What makes Rails special is how it utilizes Ruby’s advanced features to set up a framework where you can truly Not Repeat Yourself to the maximum extent possible. Look into routes, flash, helpers, filters, callback, validation, and observers before making these kinds of snap judgements. ...
http://www.killerphp.com/articles/will-ruby-kill-php/.
...
Ruby has a long way to go, I can’t argue for the programming details as I still like my Perl but from the SysAdmin side Ruby and Rails for the matter are an absolute nightmare. Ruby in itself is slow, doesn’t understand threads like every other language out there so it doesn’t integrate into apache like PHP or Perl or Python or the other hundreds of web scripting languages. Until Mongrel came out you were forced to use fast_cgi, which is a dead method of rendering pages, apache’s mod_fcgi is crap and lighttpd’s fcgi is better but the server itself is not stable enough for production. Ruby has to start by modernizing it’s preprocessor before it even has a small chance in hell of overtaking PHP and even then Rails has a long way to go before it’s ready for the primetime, the ease at which a programmer can cause Rails to leak memory is astounding. I have a shared server with 40 Rails sites running and I have to restart them every week or the box swaps and that’s with 4G of memory, most of these sites aren’t even that intense. On the other hand one of my mod_perl servers has over 100 ecomm type sites and they run just fine of 2G. So the answer is no, Ruby will not overtake PHP in the distant future.