The title is trollish: <i>concurrency</i> is not a "myth" in either Ruby or Python -- you just need to use the appropriate techniques (process-level parallelism, non-blocking I/O, etc.) to achieve it. The existence of the GIL is well-known.
GvR gave an interesting answer on Google's "Ask an Engineer" app, to a question about adapting Python to multi-core architectures:<p><a href="http://moderator.appspot.com/#15/e=c9&t=ff&q=2f40&v=4" rel="nofollow">http://moderator.appspot.com/#15/e=c9&t=ff&q=2f40...</a><p>His answer: threading is not worth it, and something Actor-like built on top of the new multiprocessing module should be written eventually. (Pythonic, no?)
There's other options beyond using JRuby for doing true multi-threading in a dynamic language. Perl has had true threading support (perldoc threads, perldoc perlthrtut) for a while now.<p>I agree that for most cases non-blocking I/O and select()/epoll() makes more sense, but there are cases where true concurrency (threading or multiple processes) is needed and either memory needs to be explicitly shared (IPC is too costly/complex or memory requirement is high) or the cost of spawning a new process is prohibitive (you're dealing with an SLA).
I actually think this is a good thing.<p>Writing (correct) multi-threaded programs is actually really hard to do. The underlying philosophy of both Ruby and Python is that the programmer's time is more important than the computer's. Using multiple processes instead of threads may require slightly more memory and computation time, but the programmer will spend less time debugging.