[f1shy]

In my experience 99% speculative and WRONG. Who said: "early optimization is the root of all evil"? :) Today more and more is possible to have a GC without terrible performance issues. Some weeks ago I read an article here in HN, about LISP used for safety critical systems. That bad fame of GC comes from the early versions of Java... but I've been using GC languages a LOT, and never had those "stop the world" moments.

[ncmncm]

The expression is "premature optimization". And, Donald Knuth.

GC overhead is always hard to measure except end-to-end, because it is distributed over everything else that happens. Cache misses, TLB shoot-downs. Mitigations are very difficult to place.

Practically, you usually just have to settle for lower performance, and most people do. Double or triple your core count and memory allocation, and bull ahead.

[Gibbon1]

Not my bailiwick but I feel like early Java's problem was a combination of everything not a simple primitive is an object that goes on the heap plus a GC optimized for batch throughput vs latency. Bonus it's Java all the way down to the bitter end.

I'm with you. One should look at latency requirements and the ratio of profit vs server costs when making a decision. AKA when your product generates $250k/month, you're paying three programmers $40k/month, and your AWS bill is $500/month isn't the time to try and shave pennies.