But it's still not a guarantee

And yet: You’ll still be limited to two simultaneous calls to your REST API because the default HTTP client was built in the dumbest way possible.

I absolutely love how easy multi threading and communication between threads is made in Go. Easily one of the biggest selling points.

python has way too many ways to do that. asyncio, future, thread, multiprocessing...

Experimentally, yes

Are you still using matlab? Why? Seriously

In this case, it's a feature of the language that enables developers to implement greater amounts of parallelism. So, the developers of the Python-based application will need to refactor to take advantage of it.

From memory I can only answer one of those: The way I understand it (and I could be wrong), your programs theoretically should only need modifications if they have a concurrency related bug. The global interlock is designed to take a sledgehammer at "fixing" a concurrency data race. If you have a bug that the GIL fixed, you'll need to solve that data race using a different control structure once free threading is enabled.

I know it's kind of a vague answer, but every program that supports true concurrency will do it slightly differently. Your average script with just a few libraries may not benefit, unless a library itself uses threads. Some libraries that use native compiled components may already be able to utilize the full power of you computer even on standard Python builds because threads spawned directly in the native code are less beholden to the GIL (depending on how often they'd need to communicate with native python code)

JG Memoryworth