I don't think there's anything wrong with Ruby as a language, and until it was added to most languages, the scaffolding held me in awe...
I just prefer Python's readability.
I'm not sure what you mean by "the scaffolding", could you please explain?
The #1 thing I like about Python is the community and has nothing to do with the language. I find the python community doesn't actively champion the language as the end all be all (for better or worse). Rather it is accepting of when Python sucks for a specific task.
I also find Ruby to be really web focused. Python tends to have lots of libraries that are not solely for web based needs. Not to say Python doesn't have web stuff...there is so much I can't even keep up.
1. While Python and Ruby are roughly of the same age, Ruby was only popular in Asia before Rails. At that point Python already had a solid base of non-web stuff.
2. Ruby feels more wild and crazy to me. Is monkey-patching still considered cool in the Ruby community? As a Pythonista I try to avoid such confusing stunts.
Due to both of those reasons I believe Python has more solid libraries. For example, Rails was extracted from a small productivity app, while Django was extracted from a serious newspaper website. While Ruby was fixing memory leaks, the Python interpreter was speeding up its hash map.
As a language enthusiast I envy Ruby for the blocks. As a Python programmer I never felt the need for them.
I think one of the reason why Python isn't hurt by the lack of blocks is the difference in namespacing rules. Since defining a top level function doesn't pollute the global namespace, there's much less of a need for blocks and mulit-line lambdas. If I feel that I've got too many functions sitting around in one of my project's files, I can simply open up a new file, utils.py, and all my utility functions will be in their own namespace.
So, I agree, blocks are cool, but when it comes to re-reading code, I like that I've been forced to spend the extra few seconds to give my functions names.
It can be useful in your particular project to overcome library incompatibilities, but it probably shouldn't be used in library/framework code.
Having a fast way to interface C code, and speed up your bottlenecks is a godsend for anything that isn't a strict web app.
I'm sure Ruby has an FFI, and most likely even has a SWIG interface but Cython is far beyond that--its a typed version of Python that compiles directly down to C/C++, so you can port code between Python and Cython instanteously.
Doing just that usually makes it 2x faster. Annotate it with types to make it more than 10x faster. Change the algo to something you can only do efficiently in C, and it's 100-1000x faster. Seeing something go from taking 10 minutes to taking 600ms in less than a days work is fantastic.
----
Also personally, I find I like white-space scoping. Python is like psuedocodethat actually runs.
The trick is to write readable code, and Python encourages that at every step. The Python mantra is "don't be clever". Compared to Ruby, where developers routinely vie for the most clever way to do something that may or may not (and usually isn't) in the interest of readability.
Also, the significant whitespace enforces the readability of Python vs. something like Perl, which is a very information-dense and, in the opinion of myself and many others, a substantially less readable language.
Either way, for my money, having used both languages extensively, Python proves to be more readable over the long haul. YMMV.
Python is also pretty good at web development, but is also excellent at scientific computing and visualization, data processing, statistical analysis (including nice bindings to R), network servers using twisted, natural language parsing, GIS analysis, computer vision and image processing and so on. Python also has Cython which makes it trivial do use C to speed up crucial functions.
Basically I prefer python because I can use the same language for everything I need and want to do.
Sure ruby could, but it would have to play catchup adding things like sage, cython, numpy, scikits etc etc
One of the differences I see is Python's philosophy of having one, correct way to do things, while Ruby supports having multiple ways. This difference in philosophy seems to be clear in the language design. Python usually has one or two accepted ways to do basic tasks, while Ruby has more.
It's a little frustrating because in Ruby, I have to remember different syntax and constructs for doing the same basic thing. I'd much rather just have to remember one way, and expect other people's code to use that one way (ie, Python is more readable).
Python also seems to have a larger community and more well-developed/useful libraries and tools. I don't think NumPy and SciPy have equivalents in Ruby.
Also, even though Ruby says it advocates the principle of least surprise, I'm often surprised by Ruby, and much less so by Python.
About 7 years ago I tried really hard to get into Python because someone I know at Google really liked the language, and I needed to pick up a better scripting language (I dislike Perl). I used Python a lot for about a year, reading a few books, using it for a lot of small projects. Python was nice!
Then I started looking at Ruby, and for me it was programming language love at first sight. I can not justify my strong preference for Ruby on technical grounds, rather I simply prefer it. Ruby is no longer just a scripting language for me (although I write a lot of 20 line Ruby programs just to get stuff done).
So, I would argue that you should choose either Python or Ruby based on your personal gut feel, after spending time with both languages. The only exception to this advice is if you want to work for a company that prefers one over the other.
At the end of the day, there really isn't much inherent that makes Python better than Ruby. Which is exactly why the world would benefit from the eventual dominance of one over the other. Even if it is a randomly driven tipping point process.
On the other hand: Ruby vs Java vs C++, each has clear advantages in certain situations. These languages seem less likely to compete with each other.
Also there are tons of existing libraries and you don't have to implement anything but your actual business logic.
