Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected.
One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.
Immaturity of native AOT sounds like a likely culprit here. If they're after very fast startup times running classic C# is out. And native AOT is still pretty new.
You can write pure functions operating on data structures in C#, it's maybe not as idiomatic as in Go, but it should not cause problems.
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.
I'm happy to see it to be honest; at this point C# is 25 years old, and since then there's been a lot of innovation and development in programming languages and ecosystems (as well as 10x more software developers, at least - I am guessing at this number). Current-day programming languages, including Go and Typescript, will have had a lot of learnings from C#, including in things like generics and the like.
Go is a step back in key areas: generics, nullability, functional constructs, concurrency. The praise of the latter in particular is egregious. Surely we can do better than having to wire the transfer of data and forking/joining the logical flows manually in 2025? The concept of virtual threading in Go, despite having nice implementation, did not progress much from what we’ve had 10 or even 20 years ago either. It can be more convenient than async/await with hot-started tasks/futures if you predominantly are dealing with sequential code. But for highly concurrent logic working with goroutines is more ceremonious.
