>Python still doesn't have "proper" multithreading because RC is too slow.

RC speed is not even close to the reason Python doesn't have proper multithreading.

(The GIL, and API/ABI guarantees to third party C-based extensions making it difficult to remove it, is more like it. The GIL was added to aid in RC atomicity - but it's not the speed of RC that's the issue).

> Go has an extremely fast GC that has minimal pauses.

Actually, I've heard that Go sacrificed speed big time to minimise its pauses. Garbage collectors generally face a latency/throughput tradeoff, and I believe Go is no exception.

That said, fast GC with reasonable pauses existed long before Go. I personally know of OCaml and its generational, incremental GC. I expect Go built on that knowledge to find its own sweet spot.

Any memory allocation scheme faces that trade-off, more or less; especially so in a concurrent environment that also employs parallelism.

Precisely. That’s why I was suspicious of this claim that there is a GC out there that is both "extremely fast" and has "minimal pauses". Something’s got to give.

Has anyone tried to build a transpiler from Python to Go?

There are versions of Python without RC: https://www.python.org/download/alternatives/. There is no doubt that Python would be better off without RC, the problem is that Python extensions rely on RC. So CPython (the main python implemenation) can't just do the switch.

If you want more information about this topic, there is a nice talk by Larry Hastings: https://www.youtube.com/watch?v=pLqv11ScGsQ

Thanks. It seems that the JyNI project is trying to make a bridge between CPython and Jython, so from that I take that it is somehow possible to have extensions which more or less rely on RC (or at least the C API) while you can use a GC (Java's GC in this case) at the same time.

https://www.jyni.org/

Unfortunately, the real test of "is this language proper python" is "it behaves exactly as the horrible bytecode interpreter in PyEvalFrameEx C function".

So it's hard to make alternative implementations that don't die.

Which one would you say is a relatively better bytecode interpreter? I was looking for one.

One that has a spec and test suite for the implemented VM, for starters.