And I'm saying this as a C# dev that never wrote anything in Go.
I would highly recommend golang to old school C# devs who are very comfortable with threading, thread safety, and mix of high and low level code in the same codebase.
edit: Best go devs I know are seasoned C or C# backgrounds.
https://www.techempower.com/benchmarks/
You should learn to write some Go code then.
Why? C# fits the bill for everything I want to do. It's fast enough, it has great IDEs, it runs almost everywhere and there are more UI frameworks than there are JS frameworks /jk ;).
I have almost 15 years experience in it, why would I slow down my next projects by using a language I'm not familiar with (as long as C# fits the bill ofc). Learning a new language isn't a hobby for me, it has to be useful to me (I learned Flutter because MS Ui frameworks aren't a panacea).
So then we come these kind of assertions like Go compiles faster than any other AOT language, it doesn't have a runtime, its performance beats Java/.NET and so on.
Note the difference between “Go is better for certain cloud applications than Python, NodeJS, etc” and “Go is better than all other languages, full stop”.
Go would lose in performace benchmarks that make heavy use of generics or SIMD code in .NET, because:
1) We all know the current state of generics in Go
2) Currently most of the SIMD support in Go is basically "write your own Assembly code in hex", because many of the opcodes aren't even supported by the Go assembler
Then there are other factors like since .NET 6 there is the possibility to use a JIT cache with PGO, and there is only so much a single AOT compilation can bring into the picture, specially since Go tooling isn't that big into making use of PGO data.
Or the fact that .NET was designed to support languages like C++, so there are enough knobs to turn if one really wants to go full speed.
Naturaly because hating Microsoft and their technologies is fashionable, few bother to actually learn the extent of ecosystems like .NET actually offer in detail.
You're definitely projecting something here.
https://devblogs.microsoft.com/dotnet/grpc-performance-impro...