Python vs Ruby

    This flame-forming article aims to gather relevant information on the advantages of Python over Ruby and Ruby over Python in one place. Based on my many years of experience using both languages, I tried to limit comparisons between languages ​​as such and their standard libraries - comparisons of web frameworks, development environments, and available libraries are not included in the article, since a lot of copies are broken here without me.


    Let's start with Python, because alphabetically


    • The documentation is much better than Ruby. With an introductory part, literary digressions and numerous examples. Ruby has many modules, such as DL or Win32API, which are not documented at all, and the documentation as a whole is much weaker.
    • The real threads of the operating system are used. Despite the fact that both languages ​​use GIL (global interpreter lock), the use of real threads will allow Python code to perform blocking operations in separate threads - for example, calling a shell script or operating system functions - without blocking other threads. In Ruby prior to version 1.9, one real thread was used, and switching between language threads was emulated. In practice, this leads to the fact that if you call a shell script (for example, copying files) or a function of the operating system (for example, show a window with a message) in a separate Ruby thread, then all other threads in this script will stop. Starting from version 1.9, Ruby uses real threads of the operating system, but at the moment (version 1.9.
    • Unicode support - in Ruby, it appeared only since version 1.9, the transition process to which is still far from complete.
    • Support for named function arguments. In Ruby, this approach can be emulated by passing a dictionary as the last argument, but this increases the amount of code.

    • Very nice ctypes built-in library for interacting with the operating system. The ruby ​​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 link to it can be placed in a variable, an array, passed to another function. In ruby, the identifier of a function is itself a call, so to pass a reference to a function, you need to wrap it in an intermediate object, “proc”, which complicates the code.

    • Support for decorators - 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, it requires a bike with this very introspection, which is also not very fast.

    • Native JSON support. In ruby ​​- only starting with version 1.9
    • Native SQLite support. Ruby has no built-in database tools.
    • The built-in GUI, “Tk,” is equally well supported on all platforms. Ruby also has Tk, but the installer for Windows doesn’t install it by default, and in OSX starting from 10.6 it doesn’t work for the Ruby that comes with the system and you need to recompile it, which is generally not very simple.
    • In Ruby, an exception thrown outside 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.
    • Supported named capture groups in regular expressions. In Ruby - only since version 1.9
    • In general, more common. If any program or library has 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 is in a very distant future. Ruby is now actively transitioning from incompatible branches 1.8 to 1.9 - quite painful, painful and generates jambs.


    Got the impression Python is better? We look from the side of Ruby


    • Interpolating strings allows you to include Ruby code in strings, automatically substituting the result of its execution into the string.

    • Native openssl support. For python - either use ActivePython with a not very convenient and poorly documented pyopenssl implementation, or install the more convenient m2crypto yourself - which is not very easy to install, especially under windows.
    • Support for creating internal DSL: blocks, instance_eval, function call without brackets.
    • A convenient mechanism for invoking shell commands and getting the result of their work is just two `characters. It works correctly with paths containing spaces - which can not be said about the subprocess module in Python, where to work correctly with spaces you have to pass the command and its arguments not with a string, but with a list.
    • Ability to include modules on a relative path. Python technically can, but with a lot of code and some unpleasant special effects.

    • Native OLE support in Windows. Python has a good pyWin32 module - but you must either install it manually or install ActivePython where it comes bundled.
    • Indexing outside the collection returns nil, which in some cases allows writing very concise code.
    • Convenient syntax for suppressing expected errors.

    • A good erb template engine is included in the standard library.
    • Ability to create temporary folders with automatic deletion. In Python, such an opportunity appeared only in version 3.2 - and this is a very distant future.
    • There is a language construct switch. But in python - no.
    • Starting with version 1.9, named capture groups in regular expressions can be automatically turned into variables.

    • Better support for working with time and date. The Python standard library does not even work with UTC.
    • Reading file contents in Windows without special effects. In Python, the file opens by default in "text mode", which automatically converts line feeds and interrupts reading when the magic EOF symbol is reached, which can lead to unpleasant bugs.
    • Threads have an exit method that allows them to shut down a thread from the outside. In Python, you cannot stop the work of the stream "outside" - you need to build your own bikes with the stop flag.


    conclusions


    We check the list and select the language for the task. Ruby is traditionally better at handling text processing, DSL, shell automation (we look at rake and envy). Python - multithreading, GUI, bindings 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 compared to 1.8.x. Questions, comments, flame? Welcome to the comments.

    PS Anticipating comments of the form "but for <comparison point> I like <language> more because <reason>". The felt-tip pens are different in taste and color, I tell from the belfry of my practical experience and my tasks, which, moreover, are far from site building. The article describes the differences.which I placed as “strengths” and “weaknesses” exclusively on my subjective, albeit professional, view. I hope the article will become a kind of basis on the basis of which developers can choose a language for their tasks a little more consciously.

    PPS Anticipating comments of the form "in <comparison point> the code for <language> is spelled incorrectly - this is done differently." Examples are exaggerated and compare the same features of languages, without taking into account the best practices of their application. Solely in order to prevent swelling of the article. I want to be compact.

    Also popular now: