C# is my goto language for productivity. If you want to lure us in, show a stereotypical example of go routines with channels solving a problem that would take significantly more effort with .net threads or .net tasks. We'll be intrigued enough to look further, and most won't stop to ask if channels seem like a recipe for deadlock/panic that's usually not the right abstraction. Don't mention the lack of generics; you'll scare us away before we get addicted to go routines.<p>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.<p>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...
"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"<p>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.<p>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.
> Go programs compile down to a single binary with all dependencies included. In contrast to C#, no runtime is needed, so applications may run in very thin containers such as scratch or alpine.<p>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.<p>> 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)<p>These are pretty important stuff that Go is lacking.<p>> 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<p>This isn't really much of an issue.<p>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".