Show HN: An introduction to Go for C# people
kfcampbell.comC# 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.
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...
"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 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.
Serious question: Why?
C# is faster, more productive, has better tooling, and generics.
C#er here. The .NET world is confusing and hard to navigate if you haven't being doing it for years. The various flavours of .NET. The various ways of doing concurrency depending on what version it was introduced in. It's actually quite hard to get a project running in .NET core with EF for example from what I found. VSCode crapped out trying to install Nuget packages. I mostly use classic .NET. A lot to be said for getting started quickly. I have not used Go but I imagine it's great at that. Quickly compile to a single binary and ship that.
I did some benchmarks at some point, and for me:
Go was faster, Go use (a lot) less memory, much easier to distribute the application, and I don't need generics (even though I like it)
Well, that's a highly-opinionated statement :P
The serious answer is that Go is a reasonably well-supported language at GitHub, and C# isn't at the moment.
Opinionated +1 :)
The C# compiler is called Roslyn which might not be obvious for people trying to find it on GitHub - it's incredibly well supported, regularly updated, and lively:
What means well-supported language at GitHub?
Go compile to native binaries, and is used for a lot of tools and CLIs.
why Go when you have C#?
> 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".