| > 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. 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". |