This is a great article, raising many valid points around concurrent programming. I can't speak to Ruby, but Python supports, and has never presumed linear programming.
Python has had POSIX threads since at least 1.5.1. The standard library contains a set tools for concurrent programming (see the threading module, queue, etc) and many included libraries are thread-safe.
The GIL's behavior is complex, but even so it's still possible to write performant, multi-threaded code in Python, especially for IO bound tasks. See David's excellent write up: http://www.dabeaz.com/GIL/gilvis/index.html.
Everybody wants the GIL to be removed, and several attempts have been made, but the collateral damage seems just too great at the moment - C extensions, and tons of libraries, frameworks, and programs would need to be re-written at the cost of greater complexity, for questionable performance gains in the average case.
Backwards compatibility is a core philosophy of Python, one which I think makes it a great programming environment. This makes removal of the GIL more a philosophical problem than a technical one. Python 3 has made some progress in removing GIL contention, but it's certainly here to stay for the foreseeable future.
Perhaps Python will be left behind in the future due to these decisions, but given all the work being done, I find it hard to believe any argument claiming that the Python community isn't actively invested in concurrent programming.
Python has had POSIX threads since at least 1.5.1. The standard library contains a set tools for concurrent programming (see the threading module, queue, etc) and many included libraries are thread-safe.
The GIL's behavior is complex, but even so it's still possible to write performant, multi-threaded code in Python, especially for IO bound tasks. See David's excellent write up: http://www.dabeaz.com/GIL/gilvis/index.html.
Everybody wants the GIL to be removed, and several attempts have been made, but the collateral damage seems just too great at the moment - C extensions, and tons of libraries, frameworks, and programs would need to be re-written at the cost of greater complexity, for questionable performance gains in the average case.
Backwards compatibility is a core philosophy of Python, one which I think makes it a great programming environment. This makes removal of the GIL more a philosophical problem than a technical one. Python 3 has made some progress in removing GIL contention, but it's certainly here to stay for the foreseeable future.
Perhaps Python will be left behind in the future due to these decisions, but given all the work being done, I find it hard to believe any argument claiming that the Python community isn't actively invested in concurrent programming.