I would write it up but you're not allowed to (check the license that comes with windows server and the .net SDK).
Anecdotal evidence points to go being faster on nearly all counts bar regular expressions once you know what you are doing. The GC differences come from the fact that go does a hell of a lot less allocations. It's possible to write complex code in go which doesn't allocate or GC at all. The same is not true for the CLR. Fundamentally the GC in go is slower and causes more pauses but you can easily tune around it without shitty hacks like the disruptor pattern.
Anyway numbers cannot be published thanks to Microsoft's suspicious intentions with their EULA so you'll have to compare yourself behind closed doors.
I've read the EULA, it's mostly about best/fair practices when releasing benchmarks to the public. But having this codified in the EULA must give legal departments the shivers! I'm surprised there are no perf benchmarks on the web comparing Go....to anything! The last I heard they were way behind even the JVM on perf; just because they ahead of time compile doesn't give them much of a natural advantage here (since JIT compilation is not a perf problem in practice).
.net has value types that you can use to avoid allocations. I've used them to write GC free code before where it's necessary, like doing a physics engine. I'm not sure if this is comparable to how you are avoiding GC in Go.
Anecdotal evidence points to go being faster on nearly all counts bar regular expressions once you know what you are doing. The GC differences come from the fact that go does a hell of a lot less allocations. It's possible to write complex code in go which doesn't allocate or GC at all. The same is not true for the CLR. Fundamentally the GC in go is slower and causes more pauses but you can easily tune around it without shitty hacks like the disruptor pattern.
Anyway numbers cannot be published thanks to Microsoft's suspicious intentions with their EULA so you'll have to compare yourself behind closed doors.