The GIL (in Python, can't speak about Ruby) is a controversial issue because people assume its bad and Python is therefore bad at concurrent programming etc. Without the GIL, the implementation would be drastically more complex and slower because all built in datatypes, dictionary lookups (for method lookups) etc would need to be made atomic, through locking. I think I can live with the GIL in this case - use threads for asynchronous (rather than parallel) code and use processes (and Python 2.6's multiprocessing library makes this easy) for parallel code execution.

Having said that, I welcome Google's unladen swallow and hope they succeed in removing the GIL.

That's not strictly true. Take a look at http://plausible.org/nasal for an example of an interpreter (mine) in the same broad space as Python and Ruby, yet without a global lock for anything but garbage collection (fixable -- there's no reason in principle preventing a concurrent GC from being dropped in). In tests of CPU-bound code without excessive allocation, it scales to 4-way SMP without trouble.

Sorry, I meant in Pythons case. Obviously theres plenty of virtual machines/interpreters/compilers which do not have a GIL and work perfectly fine.

Here are some of the reasons Python uses a GIL: http://www.grouplens.org/node/244#comment-2493

Pasted for convenience:

""" Python has a GIL as opposed to fine-grained locking for several reasons:

--- It is faster in the single-threaded case.

--- It is faster in the multi-threaded case for i/o bound programs.

--- It is faster in the multi-threaded case for cpu bound programs that do their compute-intensive work in C libraries.

--- It makes C extensions easier to write: there will be no switch of Python threads except where you allow it to happen (i.e. between the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros).

--- It makes wrapping C libraries easier. You don't have to worry about thread-safety. If the library is not thread-safe, you simply keep the GIL locked while you call it. """

"Python-stackless avoids this problem"

Not really. Stackless Python still has a GIL, and if you want to make use of multiple threads, the GIL will still bite you.

Stackless allows you to write coroutines and has lots of cool abilities, but avoiding the GIL is simply not one of them as far as making use of multiple cores.

FWIW, JRuby does not have a GIL, plus you get to use java.util.concurrent.* classes in your Ruby code.

Jython doesn't have a GIL either. Nor does IronPython.

Why is everyone so concerned with multi-core concurrency withi languages like Python and Ruby? Adding another processor will get you, best case, a 2x speedup. Rewriting in, say, OCaml or Haskell will get you a 25x speedup.

25 processors buys you a lot of programming time.

Adding another processor to my computer is quick and easy. Rewriting an application in another language is slow and hard.