Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a boss who is convinced learning Rails is too steep a learning curve and not cost effective from a labor standpoint when straight Ruby running as a CGI app on Apache is available. He is proposing, for our rewrite, that we use straight Ruby w/ no framework rather than Rails (or Merb, Sinatra, etc.) I believe in my heart that this is a bad idea but I'm having trouble putting my case into words. Some ideas I've come up with so far:
Rails promotes better code reuse and better separation of concerns via MVC
A shop running rails will look more attractive to the qualified job seeker, since Rails looks better on his/her resume, is more fun to work with, etc.
(I may be wrong on this one) Rails will have better performance on Passenger because Passenger automatically pools connections to the database where as a handrolled CGI app would have to manage that itself or not at all resulting in worse performance.
Rails is a proven technology, at least certainly more than a handrolled CGI framework
Are there any reasons I'm missing or wrong about? Are there valid tradeoffs I'm not aware of?
There are occasionally good reasons for a company to roll their own framework instead of using a standard Rack-compliant framework. But "Rails has too steep a learning curve" is not one of them.
Doing it brute-force is actually more complex, rather than less. If your boss is really worried about learning curve, he should use the standard framework that has documentation and articles and screencasts and entire hosting companies dedicated to it.
Besides, Rails is dead easy to develop for. I've taught one-day workshops on Rails, and even people who have never programmed before have a working, deployed app by the end of the day. Experienced developers have an even easier time of it.
If your boss doesn't understand Rails, and rather than figure it out, he's giving you this line about Ruby over CGI...be careful. Technology left him behind 15 years ago, and he's no longer qualified to make technical decisions.
He should be moved into marketing without delay.
Does your boss have any reasons for his conviction? Other than "a feeling"? What are his real concerns - you won't have much success in changing his mind until you have worked out what his underlying concerns are. Don't be surprised if they turn out to be substantially different to what he's currently saying. He may have an irrational fear of Danes, for example.
Do you have any concrete reasons for disagreeing?
As a boss, I wouldn't be too swayed by the reasons you list so far: good design/coding practices don't need a framework, recruitment isn't your concern, performance optimisation? Don't do it? How more proven than CGI? (He might say, not me: I drink the Rails Kool-aid every day).
Is he technical in a current sense? I mean, will he be involved in coding the rewrite? If so, might he be open to a challenge? Pick a subset of features, buildable in a day or two and try it both ways. If he's not technical, why does he think your opinion is less valid than his?
If he's concerned from a cost/effort perspective, why does he believe that writing less code (and getting thousands of lines of useful, tested framework code for free) is more costly and/or more effortful than otherwise?
Someone else has already mentioned "managing up" - I suggest Googling for resources on ways to work on this.
Are there other members of a team involved? How do they feel?
Martin Fowler famously (in the Agile world at least) said something like "if your organization is not doing what you think it should, you should change your organization". There are at least two ways to read that...
I think a potentially great idea would be to use parts of RoR(Cough ActiveRecord) and roll your own stuff if it simplifies things... I'm not a framework kinda guy, I prefer libraries and a certain degree of code abstraction, which is why I could never be mistaken for a RoR fanboy... but I think getting him to use certain parts of rails, might turn into using all of rails.
Only other point I would like to make is that MVC isn't rails only and if you rolled your own then you could very easily follow that design pattern... besides rolling your own can have benefits... for one thing, you'll know exactly what everything does and how it works, self rolled would mean a leaner system, that you can modify more easily...
My final answer is meet in the middle... Ruby is EXTREMELY powerful in the hands of creative programmers... in fact, I'm in the process of re-rolling my 2 months of rapid "throw-together" php/jquery prototype into a erb/jquery site...
--Thinking out loud--
Not trying to crap on Ruby on Rails... but Rails are what trains go on... and trains do go fast... but they only go where the tracks take you. I'm more in favor of a "Ruby off Road" environment. Less speed, More control.
Using Ruby on Rails versus just Ruby is the difference between buying an automobile and welding a unicycle out of a single tire: both will get you where you are going.
At heart though, I think this is less a technological issue and more an issue of "managing up" as the decision NOT to use Rails is so laughably bad at this point as to be nonsensical.
I think you have two options:
Sort out a way to make it seem as if using Rails was your bosses idea all along. You might say something like: "Boss, I've heard what you've said and so instead of using full blown Rails, I'm just going to use it as a basic framework and do most of the work in straight Ruby."
Take the initiative to do a prototype of the development over a weekend, give your boss something provable that says: "This is clearly the way to go".
Good luck.
It's not a very steep learning curve. You might want to ask him to walk through a tutorial before making a decision.
Also, a big advantage is that RoR is a pretty popular system right now. Installing plugins is trivial, there are many deployment options already figured out--basically a lot of the work that isn't directly "Programming" will probably be easier.
And active record--it's so useful that it's difficult to imagine doing a web/database app without it any more.
Related
For the past few months i've had the feeling that i reached a boundry in my knowledge of Ruby on Rails (RoR) development. I've developed large and small applications for both big/small clients and friends / hobby projects. I know how to develop these applications and it's beginning to feel a little bit tedious. I want to take my programming skills to the next level, me having a little experience with Javascript i enduldged myself in some good Javascript books and learned alot! But now i'm back stuck at the same RoR level that i've been for the past few months. and i want to get that knowledge boost i got from the Javascript books.
I really want to contribute to alot of open source projects but when i look at the source code i get the feeling that i dont know enough of the code and that i will become a irritating burdon to the main developer(s) of the project(s). This is just some uncertainty of mine but i dont want to tire/irritate other developers...
I feel stuck and i dont know what to do to up my own level. I try to read the source codes but often i get stuck with mainly the question "why are you doing this, and what are the benefits of it? And how does it work?". I know i want to up my knowledge of both ruby and rails but i dont know how to do this. In my time programming RoR it's been very difficult for me to pinpoint my "skill level" knowing i can always up my skills. So knowing this i started with some basic Ruby books: The well grounded Rubyist and Beginning Ruby. These were great books i learned some nifty little tricks but that's about it.
Do you guys recommend any resources and or books. I don't have alot of experience with other languages than Ruby / Javascript. But i really want to learn, i don't have a solid programming background because it mainly evolved from hobby to work. I want to contribute to open source projects and work and mainly learn from other great developers. I'm stuck and i don't know where to start.
Thanks in advance.
A few books:
Eloquent Ruby
Rails Anti Patterns
Crafting Rails Applications
Then, armed with knowledge, you'll be able to read code (your first and good intuition): that's a great source of inspiration.
There's a lot of good material at Railscasts which is worth looking through. You can learn a lot about current practices, something doubly important when a lot of the Rails material out there is for 2.x or 3.0 and doesn't reflect the state of the art.
The best way to improve your skill is to find new challenges to exercise yourself. You'll need to work on general Ruby and general programming as well as improving your knowledge of the Rails framework.
Set aside time to read and understand the various APIs you're being exposed to. The more you know your toolbox, the less time you'll waste trying to do something that's already implemented. APIDock is one of the many documentation aggregators out there for Ruby and Rails. As Ruby is generally quite readable, it's even educational to browse through the source for the libraries you use and see what methods are offered as well as any insight you might gain from observing how they're implemented. Often there are interesting use cases that are never fully documented but will serve you well when you need them.
There's a lot more to say, but really, it's a long journey. That's why people write things like Teach Yourself Programming in Ten Years as a counter-point to the "Teach Yourself X in 21 Days" books plague the industry.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am still new to web framework and I am thinking of choosing either Ruby on Rails or Django. Which one should I go for as a beginner?
If you don't know either, you're maybe a little better off with Ruby on Rails...
If you are experienced with programming at all, try this: I have found that almost all of my developer colleagues decide on RoR or Django based on the language. Both are a quick pick-up, and more often than not, one of the two languages will just "speak" to you.
I'm somewhat OCD with my code (and life) and for me, Python was a better fit. I felt calm while writing it, and more importantly, calm while reading it. However, the guy that sits next to me - and I have a mountain of respect for - found Ruby to be more appealing.
So my suggestion? If you already know how to write code and the meaning of Object Oriented, spend a day with each language. Almost invariably, you'll respect one, and fall in love with the other.
THEN pick a framework :)
I have no experience in using RoR but 3 years of knowledge about Django. A very huge advantage of Django is its very good Documentation.
Especially for a beginner this might be the most important fact. Even most of the third party apps (pluggable modules/plugins) for django are document very good and are easy to use.
On the other hand Django code is in IMO more readable since its Python code - Ruby code tends to get messed up a bit faster.
I'll assuming you don't know Ruby or Python already, since that would be the number one determinate of which way to go. Having developed both Rails and Django projects, my take is that you probably can't go wrong with either, but my feeling is that Django is better oriented towards building sites for publishing, whereas Ruby is more oriented towards webapps. This is not to say that you can't build a great web app in Django build an awesome CMS in Rails, of course. But take a look at most of the high profile users of Django: NYTimes, The Guardian, Washington Post, LA Times, The Onion, AV Club, Everyblock. Those folks are more oriented towards publishing. Meanwhile, things like GitHub, BaseCamp and Twitter (partially) run Rails. So ask yourself what type of sites you are likely to be building and go from there. But really, like other posters have recommended, there's no reason no to spend a few days playing around with both and seeing what feels like a better fit.
Both are good. From experience, though, you'll get better and more up-to-date documentation most of the time for both Python and Django.
Both are GREAT!! by I prefer Rails because of:
MVC! Model View Controller.
The wide community of Rails.
Many big projects like Twitter, 37signals products are built on Ruby on Rails.
The BIG and the HUGE libraries and gems for Rails/Ruby.
and many other reasons. Well, you have to see this: Rails Django-Comparison and rails-vs-django
Amr
This is a little subjective since it can depend in no small part on your general programming background. Do you know Python? Do you know Ruby? In general, you're best off choosing the framework for a language you already know since then you're only learning one new thing instead of two.
If you don't know either, you're maybe a little better off with Ruby on Rails due to its greater mind-share in the general development community currently. This will make it easier to find help and example code online.
I want to make a community based site, which is Drupal's strength. However I also want to try other frameworks, especially Rails.
One of the best things about drupal is its huge modules library. If I were to switch to Rails, would I be able to find similar functionality freely available as plugins, or would I have to rebuild?
Does Rails have the equivalent of (as plugins or gems):
CCK/Fields?
Node Reference?
Views / Views Relationships?
PathAuto?
Threaded Commenting?
Multisite Functionality?
Apache Solr (or equivalent) Integration?
Thanks.
I'm afraid you'll probably hear this answer a lot, but it's not a suitable comparison.
Drupal is a ultimately a CMS, Rails is a framework. Apples to oranges, or perhaps even Apple Juice to oranges. Out of the box, you fire up Drupal and it does 'things': it has a database structure, the concept of nodes, interfaces blah, blah. If you fire up Rails you have an empty project.
As far as I know there isn't a "Drupal-on-Rails" project that would be a suitable equivalent. However, I can attest to the fact that there is an awful lot of Ruby/Rails community and O/S work out there and you might find something suitable. I'd also say that the level of modularity in Ruby and Rails tends to mean that the range of plugins/modules/gems one can use is much greater.
My personal $0.02. If Drupal does what you need, just use Drupal: it's mature and has a great community. It's never a good idea to try to port Project X over to a new language as a learning exercise because you'll inevitable fall into the "Well that's how it's done in language X!" trap and become disenchanted with the new system.
If you're wanting to learn Rails (which you should, it's awesome) I'd suggest you'd be best working on a small project and seeing what the ecosystem offers before deciding if it's suitable for the needs of your bigger projects.
I have to second what Govan said, but add to it.
With Drupal, unless you really want to get into building your own modules and extensions you are really interacting with an application. Even when you start using CCK, all you are really doing is flipping switches, filling in forms and defining new options for content on the site.
Ruby on Rails is two things, and neither of them bares much similarity to Drupal. You asked "How hard is it really?". To answer that you need to understand what both Ruby and Rails are. Ruby is a programming language designed to make the life of the object purist programmer simpler and more pleasant. So, the first part of how hard is it is simply to answer "how long do you feel it would take you to learn a completely new programming language, like PHP but different".
Rails is an 'opinionated' framework. It's opinionated in that it lays out how a Ruby web project should be structured, as well as providing multiple APIs for everything from database access to web presentation. To answer the "how hard is it" question for Rails then (assuming you know Ruby by this point), you have to answer how much do you need to learn about cacheing, database design, page design, RESTful programming etc etc.
It's not a short journey. you asked if there is an equivalent to CCK for Ruby and Rails which implies to me that at this point your knowledge of programming is somewhat limited. Ruby and Rails interact with the database. CCK lets you define things in a database. Thus, with Ruby and Rails you are effectively bypassing the wonderful dialogs and forms that CCK provides you with and doing the data definition bits yourself, by hand, in code.
From experience, when I've hired experts in another programming language and framework into my Rails teams, it has taken them between 1 and 3 months to get productive, and a further 3 to 6 months for their productivity to start to raise and approach that of the Rails experts on my team.
Thus, in your particular case, I would not recommend a switch away from Drupal to Ruby on Rails.
Drupal (core) on ohloh (130k lines of code) is estimated to be 34 years of work worth.
Drupal (contributions) on ohloh (modules for Drupal 4-6 (7M lines of code)) is estimated to be 2113 years of work.
That is the power of a community, and that is something that you can never replicate. I remeber there was a guy, who tried to port Drupal to python calling it drupy, but that project died before something useful ever came out of it. Even if you copy the code, you can never copy the community.
The thing you need to realize, is that each community is different. So even if you find a project that can solve your code needs in a RoR or a different language/framework, it will never be like Drupal and vice versa.
So don't try to find a replacement for Drupal, but go explore and try new things. You might end up learning new things, that you can use for your Drupal projects.
I've read this times and times again that people saying comparing drupal an ror is comparing apple to orange which is wrong.
I think the saying itself BS. Yes we want to compare apple to orange and find out which is better. We even want to compare apple to steak. Said that, they are different. Yes, we all know. I have limited experience with either. I first thought Drupal was great and can help me build the website I wanted overnight (or over a week or month) then it didn't happen (not blaming Drupal).
My impression is that, Drupal maybe still great but it has a learning curve and needs a lot of other knowledge or talents to use it well and tweak it. RoR on the other hand is a more general framework and needs programming (Drupal needs too actually).
If you are more of a web designer person with a little PHP maybe Drupal is better fit.
If you are more of a web developer type don't want to spend time looking for modules and make them work but rather do them yourself (not really from ground up) then maybe RoR is for you (with the same amount of learning). So yes they are both good for different purpose, background, etc.
For now I will go with RoR (or dJango and other ORANGEs). My 2 cents.
Rails, since version 3.0, has officially adopted the once-controversial engine way of incorporating third-party apps. this is roughly the equivalent of Drupal's modules/plug-ins, from a 10k foot perspective. To build a community-based site, you could make use of an engine called, appropriately enough, "Community Engine." http://communityengine.org/features.html"
The Rails ecosystem doesn't have anywhere near the same number of modules Drupalists have available to them, but there are enough good quality ones to cover the chief basics.
Drupal has so many strong areas, its hard for just one or two people to recreate it in a decent amount of time with any language. PHP, Ruby, Python, etc.
You have the core node system, taxonomy, aliasing, menus, users, permissions, and modules, the database api, and form api, among others.
You'd have to know how to assemble all these pieces independently and create the structure necessary for it to all work together.
It would take more than 'a few hours'. I would say, even if you are a ROR master, you're looking at a year to two years of solid consistent work to get the best parts of Drupal for a new system.
I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.
We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.
After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:
So I thought it would be about time to
set the record straight on a number of
unfounded fears, uncertainties, and
doubts. I'll be going through these
myths one at the time and showing you
exactly why they're just not true.
This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn't
founded in the many myths floating
around.
Let's Clarify!
Myth: "Ruby on Rails doesn't scale"
Bust: That is not a specific, answerable question. Please clarify.
Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:
"What precisely do you mean by 'scale'? and how do you measure it at the moment?"
It could mean:
Maximum user sessions
Average response time given load
Throughput of given concurrent scenarios per server in a fixed time.
... difficulties organising the project so a large team of developers could work on it.
There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.
There are loads of ruby-based solutions, including
caching fragments of HTML
sharding the application across multiple databases
pre-computing work that's shared between users
pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
using a front-end web server more efficiently
just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
doing less interactively and having more batch work
doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend
If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.
However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.
Make the argument from the only perspective the client understands, money!
Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.
In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:
1) Why Rails?
Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)
http://www.theserverside.com/news/thread.tss?thread_id=33120
2) Rails doesn't scale
http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html
3) Rails is just a CMS?
If they are building a CMS then recommend Drupal, not Rails
I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job
Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.
Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.
Myth: it is hard to hire a good Ruby on Rails programmer.
(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Before I asked this question I had a look through the search results for 'Ruby on Rails' here on SO. Couldn't find much, but the following (found on this page) amused me
Personally, I started using .html, moved onto php, tried ruby (hated it), discovered Python / DJango.. and have been happy ever since.
Now here's the deal. I have no personal intention of learning Ruby on Rails just yet, but it's the topic of a group presentation I am to do at the Uni (and my mates chose the RoR subject). People with a grudge against students asking homework-type questions should leave immediately.
This question is for RoR people who find it great. I hope to find those that claim RoR is the best (authors of the breathtaking testimonials to be found at RoR website). What makes RoR so outstanding? What would you like the youths of today to find out about it just before they leave the Uni with a degree. Try suggesting something that could root in their minds and perhaps navigate them the RoR way after leaving Uni.
Your answers will not only help my presentation, but could be the source of enlightenment for many.
ActiveRecord's dynamic finders:
Person.find_by_name_and_company_id('Jorge Luis Borges', 42)
rjs, writing javascript in ruby:
page['element_id'].insert_html :bottom, :partial => 'comment'
ActiveRecord's scoping
class Shirt < ActiveRecord::Base
named_scope :red, :conditions => {:color => 'red'}
named_scope :dry_clean_only, :joins => :washing_instructions, :conditions => ['washing_instructions.dry_clean_only = ?', true]
end
calling Shirt.red will query the db with the "color = 'red'" condition
the cool part, is that if you combine more than one scope eg:
Shirt.red.dry_clean_only
it will build just one query, with all the conditions and joins necessary to satisfy both scopes.
ActiveRecord's Migrations, being able to manage db structure and data using active record, just like in the app's code, with minimal sql usage.
Tools are about solving problems. It doesn't matter whether you're talking about the tools in a wood worker's shop or a programmer's. What impressed me about Rails (and still does) is that it was extracted from framework used to build real-world web apps and has repeatedly been improved by people who extended or changed it after using it to build real-world web apps. It was no mere academic exercise.
Some of the specific problems it addressed:
Getting started quickly. If you are looking to get a web application underway quickly, what better choices could you have than a framework that specifies an existing directory structure (one based on MVC), with lots of code generators, and choices already pre-made for you as to components like JavaScript library, testing support, ORM, etc. You may not agree with all the choices but you can assume them and have something that will work for 80% or more of projects and swap out something later if you have a preference.
Long term maintainability. Migrations give you ways to move data forward as your code changes, something that happens in any real-world application, yet most frameworks do not account for that at all. Separating all of the parts of your application into a directory hierarchy already setup with areas for testing, database, configuration, etc. again aids the long term maintenance of your project.
Reduced human error. Configuration files give you extra opportunities for human error. Logical conventions, once learned can avoid mistakes like the classic mistyped file name or class name in a configuration file error.
Recognition of different modes of development. Rails has built in support for the idea of having a different set of settings for development vs. test vs. production. Real apps have this too, but often the framework around them doesn't accommodate it and you end up having to swap configuration files in and out to achieve the same effect (see human error above).
Good practices. Several things I've mentioned above embrace and encourage good programming practices (MVC, standardized project layout, etc.) but Rails is often explicit in encouraging them and not just implicit. For evidence of that you need look no further than its built in support for test driven development.
I blogged in detail about why I love Rails three years ago, but for me for number one cool feature is that it makes developing web applications easy and fun.
To name a few items:
Large developer community (not saying that python doesn't)
Convention over configuration rocks
Can be used with JRuby/Warbler to make rails run on Java Application servers. Very important when trying to drag Enterprise into the 21st century (Django can be used with Jython to work with application servers, but is less mature).
MVC framework helps keep your application structured.
Scaffolding and generators to get your project moving.
Rails doesn't try to be the only way to do web applications, that's not the intent. It fulfills a specific set of needs.
This isn't a comparison against Python - it's a general list of things I like.
I write a lot less code than I would in Java
... And the code I do right is very readable and maintainable
I very rarely need to think where some code lives or how to handle a common task - it just has its place (e.g. migrations are built in)
You don't end up using lot of different technologies on one project (Java, EJB, Hibernate, JSP, SQL DDL, Ant, XML, taglibs)
Interpreted rather than compiled saves you lots of development time
One of the main reasons for me is that it puts fun back into web programming.
Suddenly things become simple and within reach. you don't need months of code crunching and
don't need tons of code written. you can do some pretty amazing things with just a few lines.
And it feels good :)
Honestly, I like the design of Django more then rails, but I like ruby more then python. Its a personal thing, because I know plenty of people who feel the opposite way, but I find ruby to be one of the most elegant languages I have ever used.
My main motivation for using Rails is ruby. I touched a lot of languages before I found ruby and I never felt I was any good in any of them. When I met ruby everything just made sense. It's a beautiful language; Easy to learn but hard to master.
I use rails because it suits my needs as a webdeveloper and is very feature rich.