Link Details

A lot of words but no real content.

I tried to talk more in concepts because I'm not sure how the community should go about what I'm suggesting they do. Sorry you didn't like it. :/

I'm with cha0sth30ry here, there's not much "umph" to the article.

correct me if I'm wrong, but I didn't really see any concrete concepts besides your personal experience related to rails (like the company you work for evaluating the rails as one of four different frameworks). You didn't really answer the post's main title/question

The only thing concrete that you've mentioned is that you have to install rails while symphony's dependencies are already built in most nix os's

Symfony has _nothing_ to teach rails.

While I agree that the article is thin on technology information, I don't understand the strong negative reaction.
I'm a Rails developer at work. Its a great framework and I am not interested in going back to Java. I have never been a fan of PHP, but I have played around with it and Symfony just to keep up with what else is out there, and its OK.
If you have to use PHP, its not bad, and some people have to/want to. I feel bad for them/don't understand them, but what does anybody care. Its much better that they have a tool like Symfony than not. It promotes some good practices in the PHP community, notibly DRY, KISS, general orginization, modularity. Traits that are often lacking in PHP projects that I've looked at.

I have to disagree with eelmore that Symfony has nothing to teach rails comment, in principle at least. It might. If not now, perhaps later. Just because Rails is one of the best web application frameworks to hit the scene, doesn't mean it can't learn something from somewhere else, and ignoring feasible good technology ideas because you didn't come up with them is foolish. The Rails team may be alot of things, but technologically foolish isn't one.
Mr. Hussey has one very valid point that should be considered Rails deployment is hard, especially compared to Symfony/PHP. This does make Symfony/PHP more attractive in many cases. Its simply a fact that getting a rails application up and running on a production site takes more effort and more 'parts', particulalry if you are constrained in the type of webserver you can deploy to (I've had to deploy to Apache 1.3 and that is no joy). I believe its worth it, and have the skill to do it, but others may reasonably (or unreasonably in the case of management mandates) disagree or simply not be confident or capable enough. This is not a fault or Rails, but it is real hurdle nonetheless. Dr. Nic Williams had an interesting post about JRuby related to this:
http://drnicwilliams.com/2007/03/23/drop-rails-into-tomcat-and-it-just-works-ola-bini-on-jruby-presentation/
As a community, Rails should look to see its faults or situations that are stacked against Rails, and do what it can to mitigate those. Share the joy people.

(I'm not saying that rails is perfect, nor am I saying that it can't learn some tricks from other frameworks like symfony.)

The negative reaction stems from the article's failure to deliver it's promise; it didn't teach us much about anything that rails needed to learn from symfony or other frameworks. To add insult to injury, the article has a page of content that could have easily been compressed to a few sentences, "rails dependencies are not delivered with the os while symfony's dependencies are". This is also stupid considering that this will change very soon (first with osx's next version) and rails deployment isn't hard (Sean even mentions this) with locomotive and instant rails solutions.

What I don't understand is why people would mod this article up if they actually read it; unless they happen to be Sean's friends / coworkers.

Well, first off, I don't know anybody who has either modded this up or down, though I'm flattered that I seem to have inspired at least 2 of the down-voters to register for this site just to bring the post down.

Second, I never claimed it was my intent to provide technical answers. I'm speaking from experience in that, even though Rails was the better choice in my situation, symfony was chosen because PHP is ubiquitous.

Third, chalk some of it up to writing style. Yes, I could have written the whole thing in 3 or 4 sentences, but what's the point in that? Terseness is for APIs, technical manuals, and the instructions you get with build-it-yourself furniture. I was trying to tell a story. If 3-4 lines is what you look for in a post (which was an answer to an open-ended question), then I'll wear your down-vote with pride.

The title of your post is "What Rails can learn from other frameworks". The "story" should be mainly about details related to what Rails can learn from other frameworks, and not mainly revolving around the minor details of your daily work life.

Either change your title to "Another day at work" or don't submit stuff like this. It's just too long for a misleading post. Like I said, I learned more about your job, you and your co-worker's preferences than I did about the concrete differences between symfony and rails.

Well, first, thank you. That was constructive criticism, which I appreciate. Had you said something along these lines at first, we might have had a different conversation.

I admit, looking back, that the title doesn't quite accurately reflect the content. I gave it that title because that was the challenge question posted at On Ruby. It makes more sense in that context. The synopsis on the dzone post is more accurate.

As for details of what Rails can learn from symfony, I said early in the post (first paragraph) that, from a technical standpoint, in my opinion, it can't learn anything from symfony. (Mr. Eelmore agrees, yet still modded the post down. Odd.) What it can learn has to do with the ease of installation, deployment, and adoption, which PHP has in spades. The concrete differences are irrelevant until we lower that barrier to entry.

I don't have the answers on how to do that, but the question posed was open-ended enough that I didn't think it was needed.

What's also not needed is me trying to continue this conversation. You didn't like the post because it took too long to get to the point, which you seem to have missed anyway. As the writer, that's my fault. Enjoy your weekend and Happy Easter.

I'm not going to get into a debate about value per letter of the article. The salient point to take from it is that the ubiquity of PHP enhaces the attractiveness of Symfony, particularly where a manager and not a programmer makes a decision.

Also the notion that Rails is as easy to set up and run in production at moderate load seems to gloss over many deployment scenarios and how challenging it can be. Ignoring the db piece because they are roughly equivalent), looking at its optimal:
Rails: Apache 2.2, Mod proxy balancer, Ruby, Rails, Mongrel, Mongrel cluster (6)
Symfony: Apache (multiple version), mod_php, PHP, Symfony (4)
Java (for the heck of it): Tomcat, Java, Spring or other MVC (I'm not up on the Java Rails copycats) (3)
Python: Apache, mod_python, python, django (4)

There are less moving parts in many other configurations so there is less to make work and less to screw up.

This also assumes a current version of apache. Not everyone has this luxury (corporations, universities, shared hosts). Where I work, I'm stuck with apache 1.3 and it was a bit of a pain to get Rails, Mongrel, Mongrel Cluster, Apache, and Pen to play nice, especially if I want to get Apache variables passed to rails (since PHP, Django are part of Apache container, its trivial).

While there are some great options such as locomotive and instant rails to get developing rails, I'm not sure how well they stack up as production deployments. I've just never heard of it, which could easily be my lack of knowledge and there are lots of well trafficked rails sights running on these tools.

Rails is two things, its a superb web application design framework, and more broadly it is a community. While this post may not enhance an understanding of a weakness in the first, it does underscore a challenge to the second. Anything the community can reasonably do to remove barriers to entry is good for the community. It helps insure that Rails will remain vibrant and help sway mangers that they should listen to their IT people and bring it into the shop. The more Rails is in IT shops, the more jobs there are for Rails developers, the more jobs there are, the higher my salary goes and the less likelyhood I have to go back to Java or switch to python to make a living. This is a case where common good aligns with self interest.

As for a future production OSX server that will have rails installed by default, I think I'll get the commodity linux box and with the money I save buy a developer Mac instead and ssh in to the server to set up Rails.