This flame-forming article is designed to gather relevant information in one place on the benefits of Python over Ruby and Ruby over Python. Based on my own many years of experience in using both languages, I tried to limit the comparison to languages ​​as such and their standard libraries - comparing web frameworks, development environments and available libraries are not included in the article, as many of them are broken here without me.

Let's start with Python, because alphabetically

• Documentation is much better than Ruby. With an introductory part, literary digressions and numerous examples. In Ruby, many modules, such as DL or Win32API, are not documented at all, the documentation as a whole is much weaker.
• These operating system threads are used. Despite the fact that both languages ​​use GIL (global interpreter lock), the use of real streams will allow Python code to perform blocking operations in separate streams — for example, calling a shell script or operating system functions — and not block other streams. In Ruby before version 1.9, one real stream was used, and switching between language streams was emulated. In practice, this leads to the fact that if you call a shell script (for example, copying files) or an operating system function (for example, show a message box) in a separate Ruby stream, all other threads in this script would stop. Starting from version 1.9, Ruby uses real operating system threads, but at the moment (version 1.9.3-p125) a lot of flaws do not allow you to take advantage of this - in particular, Ruby does not like to raise GIL when calling blocking operations, so trying to show the operating system window in a separate thread will also stop the rest - this time because the GIL will not be raised.
• Unicode support - it appeared in Ruby only from version 1.9, the transition to which is still far from complete.
• Support for named function arguments. In Ruby, this approach can be emulated by passing a dictionary to the last argument, but this increases the amount of code.
  
  
• Very good built-in ctypes library for interacting with the operating system. The dl library built into ruby ​​is much worse documented and more difficult to use - the authors recommend using gem 'ffi'.
• A function is an object - a reference to it can be placed in a variable, an array, or transferred to another function. In ruby, the function identifier itself is a call, so to transfer a reference to a function, it must be wrapped into an intermediate object, “proc”, which complicates the code.
  
  
• Decorator support - the ability to add annotations to objects that change their behavior. In ruby, this can be emulated using introspection - but the code becomes more complicated, requires a bicycle with this introspection itself, which is also not very fast.
  
  
• Native JSON support. In ruby ​​- only from version 1.9
• Native SQLite support. Ruby does not have built-in database tools.
• The built-in GUI, "Tk", is equally well supported on all platforms. In Ruby, there is also Tk, but the Windows installer does not install it by default, and in OSX, starting from 10.6, it does not work for Ruby that comes with the system, and you need to recompile it, which is not very easy in general.
• In Ruby, an exception that is not thrown in the main thread is not handled by the default exception handler.
• Support for unpacking and packing archives in the standard library.
• Good Qt library GUI support for all supported platforms. And Qt, as you know, is power.
• Support for named capture groups in regular expressions. In Ruby, starting from version 1.9 only
• In general, more common. If any program or library has a binding (VirtualBox, Qt, GTK) then in most cases it will be Python.
• Stable versions 2.6 and 2.7 almost do not differ from each other and are mainstream, the transition to 3.x - in a very distant future. Ruby is now actively moving from incompatible 1.8 to 1.9 branches - quite painful, painful and generating shoals.

Got the impression that Python is better? We look from Ruby

• Line interpolation allows you to include Ruby code in strings, automatically substituting the result of its execution into a string.
  
  
• Native openssl support. For python, either use ActivePython with a not very convenient and poorly documented pyopenssl implementation, or install a more convenient m2crypto by yourself - which is not something that is particularly easy to install, especially under windows.
• Support for creating internal DSL: blocks, instance_eval, function call without brackets.
• A convenient mechanism for calling shell commands and getting the result of their work is just two characters `. It works correctly with paths that contain spaces - which cannot be said about the subprocess module in Python, where to work correctly with spaces, you have to send a command and its arguments not as a string, but as a list.
• The ability to include modules on a relative path. Technically, Python can, but with a lot of code and some unpleasant special effects.
  
  
• Built-in support for OLE in Windows. Python has a good pyWin32 module - but you must either install it manually or install ActivePython, where it comes in the bundle.
• Indexing outside the collection returns nil, which in some cases allows you to write very concise code.
• Convenient syntax suppression of expected errors.
  
  
• The standard library includes a good “erb” template engine.
• The ability to create temporary folders with automatic deletion. In Python, this feature appeared only in version 3.2 - and this is a very distant future.
• There is a language switch construction. And in python - no.
• Starting from version 1.9, named capture groups in regular expressions can be automatically converted to variables.
  
  
• The best support for working with time and date. The standard Python library even with UTC does not allow to work.
• Reading the contents of a file in Windows without special effects. In Python, the default file opens in “text mode”, which automatically converts line breaks and interrupts reading when the magic EOF character is reached, which can lead to unpleasant bugs.
• Threads have an exit method that allows you to regularly stop the thread from running outside. In Python, you can not stop the work "outside" - you need to embed your own bikes with the stop flag.

')

findings

Check the list and select the language for the task. Ruby is traditionally better at text processing, DSL, automating the shell (looking at rake and envying). Python - multithreading, GUI, binding to everything that moves, the best documentation and support by the industry. When using Ruby, if possible, it is better to use version 1.9.x - there are too many changes for the better in comparison with 1.8.x. Questions, comments, flame? Welcome to the comments.

PS Anticipating comments like "and I like <comparison item> more like <language> because <reason>". The taste and color of the markers are different, I tell from the bell tower of my practical experience and my tasks, which, moreover, are far from site building. The article describes the differences that I have set up as “strong” and “weak” sides solely in my own subjective, albeit professional, view. I hope the article will become a kind of basis, based on which developers can choose the language for their tasks a little more consciously.

PPS Anticipating comments like "in <comparison item> code in <language> is written incorrectly - this is done differently." Examples are exaggerated and compare the same language capabilities, without taking into account the best practices of their application. For the sole purpose of preventing the article from swelling. I want to be compact.