[ncmncm]

This analysis assumes that not using GC costs something. However, in modern C++ code, as in Rust code, you can root around as long as you like and not find any code outside low-level, standard libraries that does any memory management. Avoiding GC costs exactly nothing in progress or in iteration time.

So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X.

[grumdan]

One point is that the rewrite itself costs developer time that could be spent on something else.

Aside from that, rewriting something in C++ based on code in a higher-level language with better abstractions might cost additional developer time, maintainability, and quality.

[staticassertion]

> One point is that the rewrite itself costs developer time that could be spent on something else.

But they're already advocating for a rewrite, just within the same language.

[stcredzero]

I thought someone was also advocating for rewriting something in a managed language with GC to a language like Rust.

[stcredzero]

Avoiding GC costs exactly nothing in progress or in iteration time.

This might be true in new development. The specific context in this discussion was rewrites.

So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X.

Again, you're talking about new development. That's not going to fit everyone's situation.

[ncmncm]

OK, I get you.

The problem is that whatever level of GC overhead you start with, or achieve, it will be non-zero, and its actual magnitude, including typically big cache-footprint knock-on effects that show up attributed, in perf results, to mainline processing, will be practically impossible to estimate reliably without comparing against a rewrite.

So, instead, you generally have to say: we compared some similar(-ish) program Y that was rewritten and cut the number of server instances required to meet demand by 30%, 60%, or what-have-you. But, exactly for the reasons you cite, comparisons published are against performance under GC after that optimization has already been done, as much as was practical.

[stcredzero]

including typically big cache-footprint knock-on effects that show up attributed, in perf results, to mainline processing, will be practically impossible to estimate reliably without comparing against a rewrite

It sounds like you're most familiar with, and you're arguing from a situation where the cost/benefit tradeoff overwhelmingly makes efficiency the king. So sure, in that situation, don't use GC. Write code with those cost/benefit tradeoffs in mind. That's valid, probably awesome and wonderful in certain situations. However, that doesn't mean that those particular cost/benefit tradeoffs rule over everything, everywhere, and everyone else should follow suit.

that optimization has already been done, as much as was practical

Which could mean a lot of things. I think, for the sake of your argument, you're arguing that we can assume it means, "very close to maximum optimization." Sorry, but you can't make this assumption everywhere and always. It depends. As Matt Easton says: Context!

[ncmncm]

> that doesn't mean that those particular cost/benefit tradeoffs rule over everything, everywhere, and everyone else should follow suit.

Indeed, a very great deal of code running on servers is in Python or Ruby. That's the low-hanging fruit before you start talking about GC overhead in a compiled language. But of course most of that is somebody else's code. People tend to be interested in what it costs to run their own code, not the next office over's.

If you believe your own argument, it would be foolish to start a rewrite while easy GC optimizations still await. Not everyone chooses wisely every time, but it's the charitable assumption.