I'm really tired of these disingenuous justifications and arguments to 'just use processes!'<p>A GIL is an unnecessary limitation that precludes a huge swath of architecture optimizations. It's there because it's difficult to remove once you've made the incorrect choice to rely on it, not because a GIL is a good idea.
With most web architectures, your state is outside the process (RDBMS, NoSQL, filesystem, whatever persistent store you're using).<p>So the main benefit using threads (easy sharing of in-process state) goes away. For web architectures, concurrent request handling seems to me to be best achieved by multi-process, rather than multi-thread.<p>There are some minor benefits to threading (e.g. an in-memory cache of global state can be shared amongst multiple threads, rather than being replicated among multiple processes) but:<p>- there are out-of-process cacheing technologies (memcached, redis etc)<p>- threading doesn't come "for free", in that you need to pay a performance cost in terms of locking in your interpreter and/or a code complexity cost in terms of access to your shared data structures.
Three quotes, hopefully not out of useful context, that seem incongruous:<p>"Rubinius is about the join JRuby and MacRuby in the realm of GIL-less Ruby implementations"<p>"I spend my free time working on an alternative Ruby implementation which doesn’t use a GIL (MacRuby)"<p>"I respect Matz’ decision to keep the GIL even though, I would personally prefer to push the data safety responsibility to the developers. However, I do know that many Ruby developers would end up shooting themselves in the foot"<p>So developers using GIL-less MacRuby, JRuby and Rubinius are prone to foot shooting? I wish they'd blog about this more, I've never once heard a MacRuby or JRuby developer blog saying "I went back to MRI because I needed my Ruby code to be run more safely".