I don't really get the OOP arguments from Anders. You don't need to do OOP stuff in C# - just write a bunch of static functions if you want. However, I totally get the AOT aspect. Creating a simple cli app meant for wide distribution in .NET isn't great because you either have to ship the runtime or try to use AOT which is very much a step out. I have come to the same conclusion and used Go on some occasions for the same reason despite not knowing it very well.
If doing a web server, on the other hand, these things wouldn't matter at all as you would be running a container anyway.
There are none in new projects. There are few in existing ones. I guess it is difficult to have a conversation with someone who is committed to looking for the aforementioned "gotchas".
I generally agree that C# == Java == Go in most aspects and have far more and generally think C# is nicer to use and probably faster for many use cases. But, it is not the same as Go at all in terms of AOT. In golang that is just the default and always works - basically on all platforms, in C#, that is not the case. Do you really want to find out that a popular library uses some reflection and therefore doesn't work half way through the project?
In my opinion, using C# for this use case isn't a practical choice on a greenfield project.
Where in the documentation does it state that everything just works (as it would in go)? I see a list of incompatibilities / limitations etc., that not only apply to your own code but any 3rd party library.
Read on the trimming warnings (i.e. there are none? it means everything just works) and try out a couple projects :)
Very specific areas require reflection which is not analyzable with the main user being serialization and serialization just happens to be completely solved.
If doing a web server, on the other hand, these things wouldn't matter at all as you would be running a container anyway.