Python vs Ruby
Python and Ruby are two of the most popular dynamic programming languages used in high level application development. Developers often prototype using these two languages before implementing on compiled languages because of their modularity and object oriented features. Many use Python or Ruby instead of Perl as simple scripting languages. Python and Ruby are popular among web developers as well because of their rapid development cycle, with Python boasting computation efficiencies and Ruby boasting code design benefits.
The latest stable version of Ruby is 2.3.1 released on 26 April 2016. The latest stable version(s) of Python are 3.5.1 and 2.7.11 respectively released on December 7, 2015 and December 5, 2015. Multiple current versions of Python often leads to confusion about selecting the correct version for a project. Many open source projects are still only compatible with Python 2.x, whereas the most recent book publications are for the 3.x lineage.
Object Oriented Programming
Both Python and Ruby support object oriented programming. In Ruby, even global variables are actually embedded within the ObjectSpace object. In Python, global variables have to be called with 'global' predicate except for read-only (if it is a mutable object you can edit it with a method).
In Ruby, an instance of literally any type is an object. The same is true for Python. For example, in Ruby, Class and Module instances are objects, with Class and Modules themselves being objects. However, where in Ruby all functions and most operators are in fact methods of an object, in Python functions are first-class objects themselves. A function in Python is typically declared as a member of another object (typically a Class, Instance, or Module), but can be freely passed around and attached to other objects at will. Similar effects can be achieved in Ruby by use of procs, lambdas, blocks, and even method objects that provide an object associated with a method.
Both support some functional programming constructs, but Ruby is arguably better suited to a functional programming style. Lambdas in Python are generally very short, because lambdas in Python are restricted to expressions and cannot contain statements. Ruby's lambda support is far more flexible, allowing for lambda expressions of arbitrary length. In a similar vein, Python 2.x's closure support is more limited than Ruby's thanks to its limited support for lexical scope. Python 3 introduces the nonlocal keyword which addresses this limitation by allowing assignment to variables in outer non-global scopes.
On the other hand, Ruby 1.8, which is still used widely, does not support tail-call optimization for recursive functions, whereas Python uses a decorator to implement tail-call optimization. As of Ruby 1.9 (and later), it can be compiled to support tail-call optimization. Additionally, Python more easily supports higher order functions, where functions can be passed as parameters to and returned from other functions. Ruby needs procs and lambdas to do this.
The standard CPython implementation is generally regarded as executing code slightly faster than Ruby, as of Ruby version 1.8. This can be attributed in part to the fact that Python can be compiled into "bytecode" (.pyc) before the code is run. However, major speed improvements have been made to Ruby 1.9, rendering the difference negligible, and 2.0 has seen further performance improvements.
Newer generation ruby parsers are working on improving Ruby's speed. The currently planned parser YARV is actually a VM that can also be used to execute precompiled bytecode. The new Ruby 2.1 has changed the VM method cache and garbage collection mechanism (RGenGC) which boosts up the garbage collection speed even more (seven millisecond minor marks and a 95% oldgen promotion rate are proven).
On the Mac OS X platform, the MacRuby project offers an implementation of ruby 1.9 on top of the Objective-C runtime (including its garbage collector, the LLVM compiler infrastructure and more) which more than doubles the execution speed of Ruby code. Amongst other things, MacRuby maps most Ruby core types to native Cocoa objects (for example Array maps to NSMutableArray, while Hash maps to NSMutableDictionary in Cocoa) which provides a very noticeable improvement in execution speed.
If speed is really an issue for your Python project, you also have the option to use Cython, Pyrex,Pypy (JIT) or the ShedSkin tools to compile your code into C or C++. Arguably, the mature C integration tools available to Python make it far better suited to high performance computing than Ruby.
Python sees use in automating system administration and software development, web application development, analyzing scientific data (with help of numpy, scipy, and matplotlib modules), biostatisics, and teaching introductory computer science and programming.
Ruby sees use in web application development, system administration and general programming.
Python also has come up with a web-framework named Django. Django is also getting as much attention as Rails. In terms of cloud deployment, Python can run on Google-Cloud (Google-App engine), which currently only supports Python, Java and Go. Though Ruby has very strong cloud deployment options in the shape of Heroku and Engine Yard.
Ruby code is organized into blocks, with blocks starting with various constructs and ending with the keyword "end". Python code is indentation-sensitive, with successively larger indentation meaning tighter (nested) scopes. Python's syntax has been described as executable pseudocode.
Unlike most C derived languages, the boolean expression A < B < C is evaluated in Python as it would be mathematically. That is, it means A is less than B and B is less than C.
Both languages are considered very high level languages. Each of them is estimated to have a Capers Jones language level of at least 15.
Both Python and Ruby (with 1.9) have full Unicode support, although the way that support is implemented varies.
Both Python and Ruby support multithreading. The CPython implementation has what is called the Global Interpreter Lock (GIL), which negates much of the potential advantage of using threads for computationally intensive work, there are still advantages to using threads for IO-heavy work or calling into libraries that release the GIL; Ruby has a comparable Global VM Lock (GVL) with similar consequences.
Ruby's object orientation is considered to be more 'pure' in that all functions exist inside a class of some sort. Python's object orientation is more akin to that of C++, which allows functions and statements that exist outside of classes.
There are a number of functions that are available by default in Ruby but for which in Python it is necessary to import a module from the standard library.
Python supports generators and generator expressions.
Ruby and Python both support the concept of metaclasses (a class is itself an object). Both also support class variables and methods (static methods/variables in C++).
The reference implementation of Python is distributed under the terms of the Software Foundation License, a somewhat "permissive" license that nonetheless uses a bookkeeping clauses to restrict how modifications to the software may be distributed.
Licensing terms for other Python implementations may vary, as in the case of the self-hosting PyPy implementation, which uses the copyfree certified MIT/X11 License, or the .NET Framework implementation IronPython, which uses the Apache License 2.0, a more complex and slightly more restrictive license than the Python Software Foundation License (see Apache License vs COIL for discussion of AL2 restrictions). Jython, a fairly well-known Java Virtual Machine implementation of Python, uses the same PSF License as the reference implementation of Python. Various past versions of Python's reference implementation have used other license forms that were incompatible with the GPL (see official GPL compatibility list) and some additional licenses of varying restrictiveness, though the PSF License evidently resolves such issues at least with regard to GPL compatibility.
The reference implementation of Ruby is distributed under the weakly copyleft Ruby License. The Ruby License itself originally contained explicit dual-licensing provisions allowing others to distribute under the more strictly copyleft GPL version 2 as an optional alternative to the Ruby License itself, probably offered as an option to ensure GPL compatibility. Since Ruby 1.9.3, however, the Ruby License has been amended to contain explicit dual-licensing with the copyfree certified Simplified BSD License instead of the GPL, thus making the reference implementation of Ruby into copyfree software, while maintaining GNU-endorsed GPL compatibility. Part of the reason for this change may have been compatibility questions between GPL version 2 and version 3, though a strong emergent shift in Ruby developer culture toward more-permissive licensing in general and copyfree licensing in particular is also possibly relevant (see Copyfree vs Copyleft).
Other Ruby implementations (and their licensing terms) include RubyMotion (commercial closed source implementation for iOS and MacOS X), self-hosting Rubinius (used the Simplified BSD License before version 1.9.3 release of the reference implementation), mruby (lightweight Ruby implementation distributed under the terms of the MIT/X11 License), MagLev (composed of parts under several licenses including MIT/X11 License and GPL), MacRuby (MacOS-specific implementation using the same Ruby License as the reference implementation), JRuby (JVM implementation under a series of copyleft licenses), Iron Ruby (.NET Framework implementation using the Apache License 2.0), and Hot Ruby (ActionScript implementation using the same Ruby License as the reference implementation).