The GIL is not a feature but a design problem with both Ruby and Python. Implementations of both without a GIL have existed for quite long (e.g. jvm based imple

The GIL is not a feature but a design problem with both Ruby and Python. Implementations of both without a GIL have existed for quite long (e.g. jvm based implementations like jython and jruby). It's fine; not having a GIL is an enabler. E.g. being able to run ruby on rails on an application server with threads for each connection used to be a popular thing. I've migrated a few ruby things to jruby. It's shockingly easy. Mostly stuff just works. The nice thing about everything being single threaded is that nothing will break if you remove the GIL. It will still be single threaded. It's only when you actively start using multiple threads that things might break. So, you won't have race conditions until you do that and then only if you do things that you shouldn't be doing like sharing things across threads that you should not be sharing because they aren't thread safe. Removing the GIL will simply enable people to start gradually fixing things and give them the option to use threads instead of forcing them to use completely different languages. Ractor style asynchronous programming might be a good idea for python as well. One does not exclude the other.