> sounds like cross platform AOT compiled C# not being mature and performant was a big reason

I don't think it was the performance. C# is usually on par or faster than Go.

Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.

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.

A “step out” is a single flag passed to “dotnet publish” or set in the project manifest.

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.