Some people felt that my last post was lacking substance. This post is an attempt to clarify what specific things led me to become so excited about Ruby on Rails. I hope that it also serves as a bit of a holistic exploration guide for newcomers to Ruby and Rails.
I'm also planning a follow up post covering what I don't really like and where the "magic" has burned me already. Similarly, I'd hope for that future post to act as a guide for Rails developers to get burned less frequently, a well as for Ruby library developers to do less burning.
That's great, but why compare it to "Python"? If you just wanted to write about what you liked, why not do that instead of trying to offer an empty comparison that isn't even on target any way?
I'm comparing my experience learning Rails to my experience trying to find a Python framework or arrangement of tools. The problem I've had with Python is that I need to spend a lot of time picking exactly the right subset of libraries to get something that suites me; then I need to spend a lot of time gluing them all together. I haven't needed to write any glue code at all to use everything I mention in the article.
Rails is a web framework that uses the Ruby language. Django is a web framework that uses the Python language.
Comparing Rails to Python is analogous to comparing Ruby to Rails. That doesn't make sense. Was your intent to compare Django (or Pylons) to Rails?
Certainly you know this, but the issue is that simply saying "Python" doesn't help establish a fruitful dialog. The various Python frameworks are all unique in some way, and by making a blanket statement you muddy the waters to the point where there is not a clear reference point to debate on the Python side.
I think it's simply that Ruby is used primarily for web development where Python is used in just about every field for scripting and even as a Matlab replacement in universities.
Python web development projects are distributed randomly within the much larger python ecosystem and it's hard to know what stuff everyone's working on without a lot of crawling. With ruby\rails, even your google results on topics will be more targeted because the scope of the Ruby community is more targeted.
Ruby's certainly not used primarily for web development, at least not in the same way that PHP is. Its most famous use case is in web development, but it's widely used in non-web spaces all over.
This should read "(and where Django doesn't)". A language and a framework are not the same thing.
I do not find this article any more compelling than the one it addresses. Most of these supposed superiorities are just plugins that the author likes that would work just as well in a Python framework, or straw-men. Call it, "Things I like about Ruby/Rails" and were cool. Frame it as "your language sucks" and it all comes off as fanboyism. I like Rails, but Django/Python works the way I do.
Saying that easy_install is "all kinds of broken" but in the next breath saying "Luckily there is Pip and Virtualenv" is a self-defeating argument. As it is, Ruby is well behind pip/virtualenv and the environmental isolation it gives you. And fabric / pip / virtualenv is a killer combo that makes deployment fast and easy. Rails has a Gemfile. pip has a stable-requirements.txt file. It's not rocket science.
Yes, Rake is great. Lots of things Python and Ruby projects can learn from one another. Rails 3 owes a whole lot to Django.
Haml/Sass: Meh. I don't need yet another layer of abstraction. But if I wanted to use these in Python, it would be trivial to do so. To each his own.
ActiveRecord vs Django: Use SQLAlchemy if you don't like the existing alternatives. It supports schema reflection just fine. As it is, lots if not most Django apps are written together with their database schema, and migrated together using South. For most projects, this is identical to how Rails is used.
Form Handling: I can use a ModelForm in Django, and do no mapping whatsoever. Accessing a Post dictionary is just as easy as a magically created attribute on a class. It's not that hard.
Templating: Jinja2 lets me import functions and class instances directly into a template's context, and thus keeps code where it belongs. Talk about religion all you want, but I actually work on projects that need a healthy separation between display and controller logic. Excellent coders that are also excellent designers are so rare that I have never met one. Every successful project I have been involved in has had excellent coders working with excellent designers who knew enough of one another's environments to work well together.
URL routes: Give me Regex any day!
Misc other supposed pluses: Cherry-picking. There are lots and lots of apps to pick and choose from in either platform. Some are good. Some are poor. The existence of a good app on one platform does not equate to a superiority over another platform.
Arel's query building syntax appears to be inspired by Django's QuerySets, although there are quite a few other ORMs (and other tools) that use that chaining syntax, so it could be taken from them I suppose.
Yes. Somewhat different use case, although there is overlap.
virtualenv allows you to run multiple Python projects in isolated environments on the same machine, and effortlessly switch between them. These environments are complete in that they contain separate binaries and libraries. They can contain different versions of Python.
Virtualenv is not about dependency control and application deployment. It is, however, a part of that solution together with pip and fabric.
I don't think Python sucks at all. On the contrary, I love Python. It is the primary weapon on my scripting utility belt; it will probably continue to be for quite some time.
I've used Fabric/Pip/Virtualenv, it required significantly more investment to get up and running. However, those projects are evolving/improving quickly. The Rails Gemfile worked right out of the box.
I could address the other points individually, but I guess I'm failing to make my key point: Things just worked better with less effort. Python has a huuuge set of libraries available. Finding the right subset and putting them together effectively is a laborious process. The end result isn't nearly as cleanly integrated as I'd like.
Overall, it's a matter of preference. I just found it super interesting that Rails seemed to match my preferences in nearly every layer of the stack. This is coming from someone who was incredibly picky about individual Python libraries. I spent months tuning my stack. But with Rails, I feel like I can just get work done. shrug definitely to each his own.
As a professional Python developer (and an extradinarily biased one at that: I contribute to Django regularly), this list absolutely fails to ring true for me, because I not only don't have the problems he's identifying, I find them to be our strengths.
uh, Articles like this make me sick. Why do people INSIST on comparing a FRAMEWORK to a LANGUAGE?
The one thing I've noticed about most Ruby Fan Boys is that they don't know the difference between a framework and a language. I say most because I have only talked with ONE person who knew that Rails was a framework.
There are an amazing number of frameworks for each language and there are also a lot of frameworks that draw reference from Rails. (Symfony comes to mind)
I'll reiterate one more time. Being very new to the Ruby community, I can't speak for everyone, although I suspect that I might.
Out of the box, Rails has been more pleasant for me to use than my favorite Python libraries from every category combined together via months of tedious integration and fine-tuning.
I'm not comparing a framework to a language. I am comparing an ecosystem to another ecosystem. I'm comparing Rails to what I have managed to hobble together from the best libraries available to Python developers.
I think that the tendency of Ruby developers to make this framework vs. language comparison speaks volumes about the particular whole formed of many parts. Python's ecosystem has many capable parts. I feel that it is lacking a cohesive hole. And I don't think it is due to lack of trying, just look at how many Python frameworks are out there!
I don't get it. So he listed major Rails features, then he listed a few misfeatures (that pushed me away after 4 years of Rails). And then proceeded to proclaim that something rocks and something doesn't. How about copying and pasting "Table of Contents" of two books and proclaiming that A rocks and 3 doesn't? (yes, one being a letter and another being a digit, to make it as dumb as the original title)
Ughh, what's wrong with today's programmers, particularly Ruby programmers, and their unhealthy obsession with Internet fame? Want to link-bait your way up? Then learn from the masters. Remember Zed's "Rails is a Ghetto"? That's how you do it: sensationalist title must be followed by sensationalist content.
I happen to like both. Why when one is awesome the other has to suck?
You mentioned easy_install sucks because it doesn't have uninstall. I assume you haven't had problems with Rails gem initializers where production and development environment differs by quite a lot?
pip + virtualenv is as difficult/easy as rvm. They both solve the exact same problems.
When it comes to script/console, what's so hard about python -i your/boot/file.py?
I like rakefile, but i could also live without it by using plain ol' ruby file.
Haml, isn't that whitespace sensitive? Just kid... Sass on the other hand, would be awesome if it could solve multiple IE quirks for me. There's a sass equivalent in Python called CleverCSS, I wonder if it could solve my IE problems.
ActiveRecord, I fail to see how different it is compared to SQLAlchemy declarative mode. Aren't they solving the same problem? I would also add, I fail to see the difference between Sequel and SQLAlchemy. They both are also solving the same problem.
Cannot say much about FormBuilder, I like my form in html.
Layout, partials, helpers, (arbitrary functions, defining blocks in templates, etc etc) There are so many Python template engines that solved all of this problems again and again. From another angle, you don't really need Rails for this. Merb and Sinatra could provide such separations as well.
All and all, it's cool for you to express your happiness using Ruby. But why bash others?
It's unfair to compare a programming language and a framework. Worst of all these types of articles keep coming up on HN. I guess the fanboys will keep coming, eh? :)
It's sad that many Ruby programmers think that their language is superior to another just because it's cool. I love Ruby, but I was interested in Python before learning Ruby. But somehow the language was not a fit. I think which language you like is just a matter of choice (and obviously depends on what you are doing). I would still jump at the opportunity of learning/using python because it's a pretty awesome language. :)
23 comments
[ 3.4 ms ] story [ 56.8 ms ] threadI'm also planning a follow up post covering what I don't really like and where the "magic" has burned me already. Similarly, I'd hope for that future post to act as a guide for Rails developers to get burned less frequently, a well as for Ruby library developers to do less burning.
Comparing Rails to Python is analogous to comparing Ruby to Rails. That doesn't make sense. Was your intent to compare Django (or Pylons) to Rails?
Certainly you know this, but the issue is that simply saying "Python" doesn't help establish a fruitful dialog. The various Python frameworks are all unique in some way, and by making a blanket statement you muddy the waters to the point where there is not a clear reference point to debate on the Python side.
Python web development projects are distributed randomly within the much larger python ecosystem and it's hard to know what stuff everyone's working on without a lot of crawling. With ruby\rails, even your google results on topics will be more targeted because the scope of the Ruby community is more targeted.
I do not find this article any more compelling than the one it addresses. Most of these supposed superiorities are just plugins that the author likes that would work just as well in a Python framework, or straw-men. Call it, "Things I like about Ruby/Rails" and were cool. Frame it as "your language sucks" and it all comes off as fanboyism. I like Rails, but Django/Python works the way I do.
Saying that easy_install is "all kinds of broken" but in the next breath saying "Luckily there is Pip and Virtualenv" is a self-defeating argument. As it is, Ruby is well behind pip/virtualenv and the environmental isolation it gives you. And fabric / pip / virtualenv is a killer combo that makes deployment fast and easy. Rails has a Gemfile. pip has a stable-requirements.txt file. It's not rocket science.
Yes, Rake is great. Lots of things Python and Ruby projects can learn from one another. Rails 3 owes a whole lot to Django.
Haml/Sass: Meh. I don't need yet another layer of abstraction. But if I wanted to use these in Python, it would be trivial to do so. To each his own.
ActiveRecord vs Django: Use SQLAlchemy if you don't like the existing alternatives. It supports schema reflection just fine. As it is, lots if not most Django apps are written together with their database schema, and migrated together using South. For most projects, this is identical to how Rails is used.
Form Handling: I can use a ModelForm in Django, and do no mapping whatsoever. Accessing a Post dictionary is just as easy as a magically created attribute on a class. It's not that hard.
Templating: Jinja2 lets me import functions and class instances directly into a template's context, and thus keeps code where it belongs. Talk about religion all you want, but I actually work on projects that need a healthy separation between display and controller logic. Excellent coders that are also excellent designers are so rare that I have never met one. Every successful project I have been involved in has had excellent coders working with excellent designers who knew enough of one another's environments to work well together.
URL routes: Give me Regex any day!
Misc other supposed pluses: Cherry-picking. There are lots and lots of apps to pick and choose from in either platform. Some are good. Some are poor. The existence of a good app on one platform does not equate to a superiority over another platform.
Care to elaborate?
"whole" lot is probably overstating it. But some very big key things that make Rails 3 a lot nicer to use.
I'm not a Pythonista, but are you familiar with Bunlder? Is there something that it does that pip/virtualenv would do?
virtualenv allows you to run multiple Python projects in isolated environments on the same machine, and effortlessly switch between them. These environments are complete in that they contain separate binaries and libraries. They can contain different versions of Python.
Virtualenv is not about dependency control and application deployment. It is, however, a part of that solution together with pip and fabric.
I've used Fabric/Pip/Virtualenv, it required significantly more investment to get up and running. However, those projects are evolving/improving quickly. The Rails Gemfile worked right out of the box.
I could address the other points individually, but I guess I'm failing to make my key point: Things just worked better with less effort. Python has a huuuge set of libraries available. Finding the right subset and putting them together effectively is a laborious process. The end result isn't nearly as cleanly integrated as I'd like.
Overall, it's a matter of preference. I just found it super interesting that Rails seemed to match my preferences in nearly every layer of the stack. This is coming from someone who was incredibly picky about individual Python libraries. I spent months tuning my stack. But with Rails, I feel like I can just get work done. shrug definitely to each his own.
Haml isn't a layer of abstraction any more than "1" is a layer of abstraction over "one." It's the same amount of information, just less typing.
The one thing I've noticed about most Ruby Fan Boys is that they don't know the difference between a framework and a language. I say most because I have only talked with ONE person who knew that Rails was a framework.
There are an amazing number of frameworks for each language and there are also a lot of frameworks that draw reference from Rails. (Symfony comes to mind)
Out of the box, Rails has been more pleasant for me to use than my favorite Python libraries from every category combined together via months of tedious integration and fine-tuning.
I'm not comparing a framework to a language. I am comparing an ecosystem to another ecosystem. I'm comparing Rails to what I have managed to hobble together from the best libraries available to Python developers.
I think that the tendency of Ruby developers to make this framework vs. language comparison speaks volumes about the particular whole formed of many parts. Python's ecosystem has many capable parts. I feel that it is lacking a cohesive hole. And I don't think it is due to lack of trying, just look at how many Python frameworks are out there!
Ughh, what's wrong with today's programmers, particularly Ruby programmers, and their unhealthy obsession with Internet fame? Want to link-bait your way up? Then learn from the masters. Remember Zed's "Rails is a Ghetto"? That's how you do it: sensationalist title must be followed by sensationalist content.
"Only been working with Rails for two weeks; lots more goodness to uncover"
You mentioned easy_install sucks because it doesn't have uninstall. I assume you haven't had problems with Rails gem initializers where production and development environment differs by quite a lot?
pip + virtualenv is as difficult/easy as rvm. They both solve the exact same problems.
When it comes to script/console, what's so hard about python -i your/boot/file.py?
I like rakefile, but i could also live without it by using plain ol' ruby file.
Haml, isn't that whitespace sensitive? Just kid... Sass on the other hand, would be awesome if it could solve multiple IE quirks for me. There's a sass equivalent in Python called CleverCSS, I wonder if it could solve my IE problems.
ActiveRecord, I fail to see how different it is compared to SQLAlchemy declarative mode. Aren't they solving the same problem? I would also add, I fail to see the difference between Sequel and SQLAlchemy. They both are also solving the same problem.
Cannot say much about FormBuilder, I like my form in html.
Layout, partials, helpers, (arbitrary functions, defining blocks in templates, etc etc) There are so many Python template engines that solved all of this problems again and again. From another angle, you don't really need Rails for this. Merb and Sinatra could provide such separations as well.
All and all, it's cool for you to express your happiness using Ruby. But why bash others?
It's sad that many Ruby programmers think that their language is superior to another just because it's cool. I love Ruby, but I was interested in Python before learning Ruby. But somehow the language was not a fit. I think which language you like is just a matter of choice (and obviously depends on what you are doing). I would still jump at the opportunity of learning/using python because it's a pretty awesome language. :)