Personally, I prefer actors over CSP. Async concurrency is less predictable, but race conditions don't generally happen when threads aren't synchronizing, so it doesn't matter if you're not making satellite firmware.

C# allows dynamic code compilation at runtime based on reflection. The cool part of LINQ is the 'Expressions', which allow you to analyze/rebuild the AST of code and take actions based on code structure. It's kind of like having runtime macros, except you can only make your own if you're willing to spend an hour doing something that would take 2 minutes in lisp. Keeps the DSLs to a minimum. I would miss this if I switched to go. Rust on the other hand...

This seems to be bit of an overstatement. C# as a language is stable and .NET and .NET Core aren't that apart from language standpoint. They had different focus through different set of built-in functionality that each framework has provided but with bit of overlap.

There are some libraries that support one but not another (although, for many of libraries, it is non-issue as they are often targeted to .NET Standard which supports both) but to call it "fragmented" sounds a bit too much.

C# is faster, more productive, has better tooling, and generics.

This was by design and not necessarily a bad thing. C# was meant to compile to managed code for better security and performance ( JIT ) - though people can argue over the actual merits.

> Go has no generics ... You’ll find yourself freqently writing small bits of code for operations that would be trivial LINQ statements ... Go returns errors which are then checked by the caller, rather than try/catch blocks and exceptions for error handling ... Go has no concept of awaiting an action (more on this later)

These are pretty important stuff that Go is lacking.

> Go places a strong emphasis on its applications staying up to date with the language, in contrast to the fragmentation in the .NET and .NET Core ecosystems

This isn't really much of an issue.

C# people primarily use C# to make money developing on/for the microsoft/windows ecosystem ( windows servers, sql server, IIS, sharepoint, azure, etc ). So a better way to introduce Go to C# people is to show how Go is better at interfacing with these microsoft software/servers or how Go can improve productivity within the microsoft ecosystem. Otherwise, you aren't going to have much success selling Go to "C# people".