That's the key fallacy and main reason I consider tracing GC a plague.
Programmer is part of the memory management system in most today's languages, GC or no GC.
We have only started dabbling with some languages which have some rudimentary ideas about how one can free programmer from this burden (Haskell or Prolog are examples of such languages), and, well… they don't even work.
I mean, yes, they kinda work as a programming languages and you can write working programs in these, but even in languages like Haskell or Prolog programmer is very much a part of the memory management system.
Only it no longer manages memory directly but manages subsystem which was supposed to free him (or her) from the need to be a member of said team. In practice this usually works worse than manual management.
That is what people are missing when they say that:
The main overhead of GC comes not from GC itself but from that desire of trying to drop responsibilities of the memory management system on someone or something. When people are using GC-based languages they often feel that GC frees them from the need to think about the memory management. But nothing could be further from the truth.
I remember a story when some team was struggling with the speed of a certain component and I proposed to improve performance by rewriting it with careful attention to details or how data is structured in memory. And then they asked me if I used perf, flamegraph, etc — because they have used these and achieved pretty good progress, around 10-15% speedup each quarter for 4 years…
My answer was “I have achieved 10x speedup with this rewrite which is equivalent for all 4 years of your work… if I could have 4 more years to learn to use these perfectly I may squeeze few more percents from it”.
Somehow they were not amused and I haven't got the permission to spend 4 more years trying to achieve additional speedup, but you get the idea: you can not retrofit performance and reduce memory usage well if you haven't consider yourself a part of the memory management system from the very beginning.
And if you do that then you don't really need a GC. Especially tracing GC. In fact if you do that you would actively prefer Rust to languages like Go or Java. Because Rust doesn't hide things from you (except for the cases where it usually does better than human, like with layout of
But yes, sometimes languages with GC are adequate. When you, somehow, know in advance that you would never need to try to fight excessive memory consumption or excessive slowness.
And my experience shows that people overestimate capabilities of modern computers. A lot. Basically: 9 times out of 10 when someone was saying “let's write that part in Python, it wouldn't ever be a bottleneck” year or two years down the road we needed to do something about resources consumption.
I guess if you work in a “modern” fashion and switch teams before consequence of your choices may hurt you (and they hurt someone else instead) GC may be a good thing.