That's not true. You can pool, you can call GC when needed, you can build incremental GC with bounded times, and so on.

Check stackoverflow - there's plenty of links to papers and real-world examples of fixed-time garbage collectors. Or check google scholar and read papers.

Go has demonstrated a very efficient garbage collector.

Here [1] is one from Oracle for Java.

>If your language requires a GC, it is a complete failure as a systems programming language.

Plenty of OSes are in development and/or researched using managed languages and GC. Singularity [2] is but one example. I suspect in the future that doing memory management by hand will be as obsolete as writing an OS in assembly. The benefits for security, robustness, and productivity will outweigh the costs, just like the benefits for using higher languages to develop in, while slower than hand-tuned assembly, far outweigh the costs.

[1] https://www.oracle.com/a/ocom/docs/oracle-jrockit-real-time-...

[2] https://en.wikipedia.org/wiki/Singularity_(operating_system)

And apparently no one noticed that a part of Bing used Midori for a while.

That is alrigth, according to Midori team, Windows team also did not accept what Midori was capable of, even when proven wrong.

Having a GC is non different than malloc spending all its time doing context switches to reclaim more OS memory, using the actual OS memory management APIs.

It is up to the developers to decided to use a GC based allocation, stack, global memory segment or plain untraced heap allocations.

The tools are there, naturally there is a learning process that many seem unwilling to do.

And by the way, Swift's reference counting implementation gets wiped out by tracing GCs on the ixy paper.

Realistically, having the option to use a GC is a boon for many applications. Not everything is hard realtime all the time. Some complex applications tend to have a hard realtime part and parts where it doesn't matter. E.g. a CNC machine controller does not need a guaranteed response time for the HMI or G code parser. But it needs to have a tight control loop for the tool movement.

D is a language where the GC is default, but optional. And the compiler can give you a guarantee that code that explicitly opts out does not interact with the GC and -importantly - can't trigger a GC run that way. However, as this was an afterthought, parts of the language need to be disabled when opting out and not a lot of library functionality works with that.

GC is very useful for programs that don't have any form of real time - but games are real time and thus you need to be careful to ensure that the worst case of the garbage collector doesn't harm you. Reference counted garbage collection gives you this easier than the other means. Note that I said worst case - the average case of garbage collection is better in most garbage collected languages.

One of my first (after awhile) forays into C++ was to analyze big WFST graph to find various statistics. And I found that my program spent as much time freeing resources as doing actual work. Subjectively, of course, yet.

I knew it can happen, so it was not big surprise.