Why is Ruby more suitable for Rails than Python?

Python and Ruby are usually considered to be close cousins (though with quite different historical baggage) with similar expressiveness and power. But some have argued that the immense success of the Rails framework really has a great deal to do with the language it is built on: Ruby itself. So why would Ruby be more suitable for such a framework than Python?

There are probably two major differences:

Ruby has elegant, anonymous closures.

Rails uses them to good effect. Here's an example:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

Anonymous closures/lambdas make it easier to emulate new language features that would take blocks. In Python, closures exist, but they must be named in order to be used. So instead of being able to use closures to emulate new language features, you're forced to be explicit about the fact that you're using a closure.

Ruby has cleaner, easier to use metaprogramming.

This is used extensively in Rails, primarily because of how easy it is to use. To be specific, in Ruby, you can execute arbitrary code in the context of the class. The following snippets are equivalent:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

In both cases, you can then do:

Bar.new.hello  

which will print "HELLO". The class_eval method also takes a String, so it's possible to create methods on the fly, as a class is being created, that have differing semantics based on the parameters that are passed in.

It is, in fact, possible to do this sort of metaprogramming in Python (and other languages, too), but Ruby has a leg up because metaprogramming isn't a special style of programming. It flows from the fact that in Ruby, everything is an object and all lines of code are directly executed. As a result, Classes are themselves objects, class bodies have a self pointing at the Class, and you can call methods on the class as you are creating one.

This is to large degree responsible for the degree of declarativeness possible in Rails, and the ease by which we are able to implement new declarative features that look like keywords or new block language features.

Those who have argued that

> the immense success of the Rails > framework really has a great deal to > do with the language it is built on

are (IMO) mistaken. That success probably owes more to clever and sustained marketing than to any technical prowess. Django arguably does a better job in many areas (e.g. the built-in kick-ass admin) without the need for any features of Ruby. I'm not dissing Ruby at all, just standing up for Python!

The python community believes that doing things the most simple and straight forward way possible is the highest form of elegance. The ruby community believes doing things in clever ways that allow for cool code is the highest form of elegance.

Rails is all about if you follow certain conventions, loads of other things magically happen for you. That jives really well with the ruby way of looking at the world, but doesn't really follow the python way.

Is this debate a new "vim versus emacs" debate?

I am a Python/Django programmer and thus far I've never found a problem in that language/framework that would lead me to switch to Ruby/Rails.

I can imagine that it would be the same if I were experienced with Ruby/Rails.

Both have similar philosophy and do the job in a fast and elegant way. The better choice is what you already know.

Personally, I find ruby to be superior to python in many ways that comprise what I'd call 'consistent expressiveness'. For example, in ruby, join is a method on the array object which outputs a string, so you get something like this:

numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"

In python, join is a method on the string object but which throws an error if you pass it something other than a string as the thing to join, so the same construct is something like:

numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'

There are a lot of these little kinds of differences that add up over time.

Also, I cannot think of a better way to introduce invisible logic errors than to make whitespace significant.

The real answer is neither Python or Ruby are better/worse candidates for a web framework. If you want objectivity you need to write some code in both and see which fits your personal preference best, including community.

Most people who argue for one or other have either never used the other language seriously or are 'voting' for their personal preference.

I would guess most people settle on which ever they come in to contact with first because it teaches them something new (MVC, testing, generators etc.) or does something better (plugins, templating etc). I used to develop with PHP and came in to contact with RubyOnRails. If I had have known about MVC before finding Rails I would more than likely never left PHP behind. But once I started using Ruby I enjoyed the syntax, features etc.

If I had have found Python and one of its MVC frameworks first I would more than likely be praising that language instead!

Python has a whole host of Rails-like frameworks. There are so many that a joke goes that during the typical talk at PyCon at least one web framework will see the light.

The argument that Rubys meta programming would make it better suited is IMO incorrect. You don't need metaprogramming for frameworks like this.

So I think we can conclude that Ruby are not better (and likely neither worse) than Python in this respect.

Because Rails is developed to take advantage of Rubys feature set.

A similarly gormless question would be "Why is Python more suitable for Django than Ruby is?".

I suppose we should not discuss the language features per se but rather the accents the respective communities make on the language features. For example, in Python, re-opening a class is perfectly possible but it is not common; in Ruby, however, re-opening a class is something of the daily practice. this allows for a quick and straightforward customization of the framework to the current requirement and renders Ruby more favorable for Rails-like frameworks than any other dynamic language. Hence my answer: common use of re-opening classes.

Some have said that the type of metaprogramming required to make ActiveRecord (a key component of rails) possible is easier and more natural to do in ruby than in python - I do not know python yet;), so i cannot personally confirm this statement.

I have used rails briefly, and its use of catchalls/interceptors and dynamic evaluation/code injection does allow you to operate at a much higher level of abstraction than some of the other frameworks (before its time). I have little to no experience with Python's framework - but i've heard it's equally capable - and that the python community does a great job supporting and fostering pythonic endeavors.

I think that the syntax is cleaner and Ruby, for me at least, is just a lot more "enjoyable"- as subjective as that is!

Two answers :

a. Because rails was written for ruby.

b. For the same reason C more suitable for Linux than Ruby

All of this is TOTALLY "IMHO"

In Ruby there is ONE web-application framework, so it is the only framework that is advertised for that language.

Python has had several since inception, just to name a few: Zope, Twisted, Django, TurboGears (it itself a mix of other framework components), Pylons (a kinda-clone of the Rails framework), and so on. None of them are python-community-wide supported as "THE one to use" so all the "groundswell" is spread over several projects.

Rails has the community size solely, or at least in the vast majority, because of Rails.

Both Python and Ruby are perfectly capable of doing the job as a web applications framework. Use the one YOU (and your potential development team) like and can align on.