Getting rid of the GIL will also immediately expose all the not-thread-safe stuff that currently exists, so there's a couple of waves you would need before it would be broadly usable.
As a python dev, pythons multiprocess/multithreading story is one the largest pain points in the language.
Single threaded performance is not that useful while processors have been growing sideways for 10 years.
I often look at elixir with jealousy.
Your anecdote adds little.
Instead of breaking decades of code, maybe use a language like Go or Rust for performance instead.
Turns out they just want a better Python.
That's Go. It gives actual types[1] and structs (so you dont have to wonder about dict, class, class with slots, dataclasses, pydantic, attrs, cattrs, marshmallow, etc). It removes exceptions and monkeypatching. It's async-first (a bit like gevent). It's inherently multicore. And you can package and distribute it without marking a pentagram on the ground and sacrificing an intern to Apep.
You just need to stop being friends with C FFI. Which is fine for web and sysadmin tools. For data science and ML/AI/DL, it's less ok.
[1] And the types are actually checked! I think a lot of people aren't really using python type checking given how slow it is and no one seems to complain. Or maybe everyone is using pyright and pyre and are satisfied with how slow these are.
Going to JS or even TS for performance would be saner, and it has a same-ish object model even.
It's also commonly used language for numerical work in general. Most of the time numpy is enough and then occasionally you'll need something not already implemented and then have to do your own bindings.
Multithreading is not really the reason why things get written in cython etc., you can easily see 100x improvements in single threaded performance (compared to maybe a factor of 2-8x for multithreading). If you care about performance you'd definitely write the performance critical stuff in cython/pythran/c.
The bindings available in Python can also be used from other languages.
Pin your version.
Either include like almost every language from JS, Java, C# to Haskell, or just list C++ and Rust. But Go is in the former category.
I say bring it.
Hmm, how is that so?
As a python dev as well, I don't have much complaint with multiprocessing.
The API is simple, it works OK, the overall paradigm is simple to grok, you can share transparently with pickle, etc.
It takes more careful planning than async in JS?, say, or goroutines.
The ProcessPoolExecutor is nice but shouldn't be necessary.