1. https://www.techempower.com/benchmarks/#section=data-r13&hw=...
2. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
1. https://www.techempower.com/benchmarks/#section=data-r13&hw=...
2. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Comparing Go and C# as languages don't seem to be the goal of this exercise, either. Instead, the article was making the point that the garbage characteristics have generational components. This is true of C#, so I would expect it to be true of Go as well. If that is the case, whatever Go's current performance numbers are, they could probably be made better by a generational GC.
Unless you seek to optimize a single application, a benchmark is meant to be broadly representative of a wide category of applications whose performance is dominated by the component being benchmarked.
For instance, an application which allocates no memory is a poor benchmark of the memory allocator, and it is also a poor general representative of program performance if most programs' performance is dominated by memory management.