The opposite, writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself that the GIL previously avoided. But, the tradeoff is that multithreaded programs could now actually achieve multithreaded performance gains.

> writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself

I'd phrase this differently: Writing correct multithreaded code will be just as challenging (or not, depending on the person and their comfort with concurrent and parallel code development) as before, but now you won't be able to get away with sloppy multithreaded code that relied on the GIL to not break.

It was correctly written to the invariant promises of the platform at the time. If Python is altering the deal, that does not suddenly make the library writer at fault.

There seems to be some confusion here. The GIL is not an invariant of Python that makes your code thread safe. Python is not altering the deal. You can still use threads to write concurrent code in Python today, and you'll still run into all of the classic concurrency related bugs.

People just mostly don't bother writing threaded code in Python today because it provides no performance benefit. That may change, and it very likely will expose many threading bugs that already exist in many libraries that just have never been found.

You're right, the GIL certainly doesn't automatically make all code thread-safe. However, it does make some operations that would normally be problematic in a multithreaded context thread-safe. Such as: appending to a list, updating a dict, modifying object attributes, and others.

https://docs.python.org/3/faq/library.html#what-kinds-of-glo...

The no-gil fork of Python makes the builtin collections thread-safe, so that will remain not an issue (see the "Collection thread-safety" section of the design doc https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... )

Why do you say code relying on the GIL is incorrect? The GIL is a documented part of Python.

A single Go thread still replaces 10 Python threads, speaking very roughly. It's a quite particular narrow set of problems noGIL would solve.

Looks like ML workloads is the primary use case here, no amount of goroutines will help you there as long as the ecosystem doesn't exist.

No it will be the same level of skill and difficulty to do correct shared memory multithreaded programming. You'll have to manually manage locks and reason about potential for deadlock or other race conditions.

If anything it will be harder as the implicit serialization of the GIL being removed means libraries might suddenly develop race conditions that you've never experienced or seen before, likely causing spectacular crashes and undefined behavior or bugs.