Great article! I found the section on "GC Assists" very informative:

> You can think of this like a tax that your goroutine must pay for allocating during a GC cycle, except that this tax must be paid upfront before the allocation can actually happen.

From this presentation [0] a while ago, I remember reading this quote:

> We also do not intend to increase the GC API surface. We've had almost a decade now and we have two knobs and that feels about right. There is not an application that is important enough for us to add a new flag.

I would expect that creating "tuning knobs" for garbage collection is a complex task. Managing the garbage collector seems like it really differs across applications. Is this why the Go team hasn't added any more ability to adjust how the garbage collector runs?

[0]: https://blog.golang.org/ismmkeynote

Author here, happy to answer questions.

All these hacks to get around what something like the JVM or .NET already expose as tunable parameters. Yet somehow the golang proponents still claim that the golang environment is somehow "better".

Are tunable parameters necessarily better? A system with more options puts the onus on the operator to get things right, which means many JVM applications need to be individually tuned.

If an autopilot can be done well, it's much better. This article reveals a spot where Go's autopilot goes haywire, but the general typical experience is much better than this.

When you're looking for getting the most out of your system, then yes. The JVM has reasonable defaults, and has recently switched its default GC to lower latency numbers at the expense of throughput (which golang already does, but it only has a single GC). The JVMs newer GCs also have fewer parameters to tune, by nature of what they do.

The JVM already runs on systems with 100s of GB and more (even TBs). golang will have issues running on such systems.

It’s not often I come across a well-written post by an engineer. This one is remarkably clear.