I loved Python since the first moment I saw it. I knew it was the language for me — and I was right.
Just now, making the blog-reading rounds, I stumbled on Guido’s Py3K FAQ with his response to why Python is keeping the GIL, which essentially makes plain-old multi-threaded programming a useless optimization strategy in Python. Well, you have to remember that he works in Google, one of the companies best specialized in designing for scaling up. His solution to proper usage of multi-core? Use different processes. So elegant, so correct, and so scalable.
After arguing so much that inter-process communication is rarely a bottleneck, and if it is then usually it is better to improve the architecture than to squash two tasks together by force, it is refreshing to see that I am not alone in my struggle. Processes, especially on UNIX-based systems, are so elegant, so robust, so beautiful in their simplicity, that they deserve more usage. Essentially, threads assume that you want to trade, by default, correctness in favor of speed. In the modern universe of software which is loaded by complexity, even the most performance-critical application should be designed with robustness and safety in mind.
So many assume the GIL is just a limitation in Python, used until someone has time to make it go away, to allow “true” multi-threaded programming in Python. However, the GIL essentially trades off simplicity for performance, making Python simpler, more robust and more predictable instead of allowing programmers to write multi-threaded applications which utilize mutliple cores. The only cases I have used threads in my Python programs recently is to wrap DB requests. I consider this a limitation of the DB interface libraries: had they used asynch interface, everything would have been simpler.