[cafxx]

There's a bunch of activity ongoing to make things better for memory allocation/collection in Go. GreenTeaGC is one that has already landed, but there are others like the RuntimeFree experiment that aims at progressively reduce the amount of garbage generated by enabling safe reuse of heap allocations, as well as other plans to move more allocations to the stack.

Somehow concluding that "By killing Memory Arenas, Go effectively capped its performance ceiling" seems quite misguided.

[pjmlp]

That one is kind of interesting given the past criticism of Java and .NET having too many GCs and knobs.

With time Go is also getting knobs, and turns out various GC algorithms are actually useful.

[cafxx]

Not sure what you are referring to. There are no knobs involved in the things I mentioned (aside from the one to enable the experiment, but that's just temporary until the experiment completes - one way or the other).

[Mawr]

That past criticism was and is correct, proven by the fact new Java GCs like ZGC were deliberately designed to offer few knobs.

Go isn't getting any new knobs, there are only two; that's nothing compared to 100's of options that old Java GCs had. Completely incomparable.

> and turns out various GC algorithms are actually useful.

I don't know what you're trying to say here, but I think I know why — you don't know either. Stop spitballing.

There are no "various GC algorithms" at play here at all. There is just a new algorithm that performs better. You can read all about it here: https://go.dev/blog/greenteagc. It's not an optional alternative GC, but a successor.