
Show HN: An introduction to Go for C# people - passivepinetree
https://kfcampbell.com/blog/2020/go-for-csharp-people-part-one/
======
caseymarquis
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.

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

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

------
CyanLite2
Serious question: Why?

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

~~~
passivepinetree
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.

~~~
JoeMayoBot
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:

[https://github.com/dotnet/roslyn](https://github.com/dotnet/roslyn)

------
may4m
why Go when you have C#?

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

