Getting rid of the GIL does not imply better performance... Currently, their implementation is quite slow, part of the reason is due to extensive use of atomic integers and RC usage.
The presence of any kind of GIL is probably my latest "will not use this language" filter, it's why I originally switched to Elixir actually (it does not require a GIL because all memory is immutable and concurrency is trivial in that case)
apparently they did
Getting rid of the GIL isn’t the hard part.
It’s getting rid of the GIL and having existing Python code continue to work, with C extensions and all.
I think the root comment is asking whether this new Python-on-Rust interpreter for rid of the GIL. Your link is about the existing CPython interpreter.
Why document something they have not implemented?
Because rightly or wrongly, tons of existing Python code implicitly requires on the GIL to function correctly. Especially when you have C extensions that may not be thread-safe.