Afaik (C)Python uses reference counting, it's slowness comes from the interpreter itself.

It uses also tracing GC to handle RC loops.

I guess doing it this way allows to have mostly deterministic collection (that is then just an implementation feature, not language semantics) while needing the actual tracing GC to not be that efficient, as it presumably needs to be executed less rarely.

Ref counting is a GC-algorithm, and the slowest at that (especially with multi-core sync, but that’s not the case with python), as a tradeoff for less memory consumption.

But you must understand, Python is safe and C is difficult. Therefore, to be fast we need Python (fast development that is because nobody _really_ cares about performance (or maintainability)).

If only more than two languages would exist!

> fast development that is because nobody _really_ cares about performance (or maintainability)

This is either

1. missing a /s

2. delusion

3. bait

I believe it's 1, considering the statement 'If only more than two languages would exist!'. Granted, sarcasm doesn't transmit well in written text.

Python wasn't designed for speed.

> You don't need to go that far for GC's bad rep considering that excruciatingly slow Python can be found TODAY!

To be fair, the GC is probably the last reason of Python speed problems.

Many languages also designed with GC performs significantly better than python in term of raw performance [^1].

The extremely dynamic nature of python associated with its reference semantics are probably significantly more to blame here.

[^1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...