My experience with Go is a while back, before it got generics. While I liked the overall idea of a language with little syntax and a focus on simplicity, I didn't really like Go in the end. It was a weird mix of too low-level and high level code. It exposed low level details that I don't need to think about in C#, and it is missing convenient abstractions like LINQ.
Personally, I like async/await in C# more than Go concurrency. I know this is heretical here, but I don't care about function coloring or any of the abstract advantages of other concurrency approaches. Async/Await in C# works for me (in non-legacy code) and is easy to understand.
I have also found c# async to be lighter than go's concurrency story, and dotnet11 is going to make that much more clear.
Now: I write software for fun, not for money.
For general concurrency where async doesn't suffice, go is nicer than C#, but hopac is nicer than go.
If go had proper concurrentML I am pretty sure I would use go a lot more. Again: this is for hobby projects where I get to choose freely.
Put things like their remote debugging experiences side-by-side and you will quickly learn why some of us go for the Microsoft tools rather than the others.
Also Go is at the stage of C# .NET 2.0, and still plenty of lacking language features.
I really think the creator of C# made a disservice to the .NET community by picking Go for the Typescript rewrite.
Sure, having a runtime is downside but difference in container size for your average CRUD App doesn't really matter. Performance IME is very similar.
Ops type here.