Generally, writing fast Go code is easier. This comes down to two reasons:
The Go scheduler will yield on sys and function calls. You simply write "normal" sequential code and it will perform really well under high concurrent load.
In .NET, we have the TPL and async await. .NET is capable of high performance concurrent code, using Tasks works well for this. BUT; you need to avoid async/await whenever possible for this. async methods will allocate a async state-machine which is expensive. (I have not measured if this is due to the allocation or the internal flow logic in the state-machine)
The problem with this is that if you want to compose a flow of potentially asynchronous operations, this becomes really tricky in .NET when avoiding async/await. You need to deal with completed tasks differently than non-completed tasks etc. Doable, but hard and makes your code non intuitive.
In Go, you generally work with primitives, slices, maps etc. This feels a bit too low level at times, but it works pretty well and is the idiomatic way to write Go code.
In .NET, you have a lot of abstractions, sorted dictionaries, linked lists, you name it, we have it. But, much of the internals of .NET was written w/o any real effort to make it performant. You cannot really know upfront if the abstraction you chose will perform well.
You can of course fall back to primitives in .NET too, but this is a lot less idiomatic.
What I am really saying here is that .NET molds you as a developer into a mindset of using abstractions, which is good for your everyday LoB applications. But you will have to challenge yourself when you try to enter the land of high perf code, re-learning how to write your .NET code.