[coldtea]

It's part of Go's typical "we assume/declare that we do better/simpler without checking what/how other languages do" schtick.

Take error handling and package management for example - different approaches, hacks piled, etc, instead of just going with the program, seeing how others do it successfully (e.g. Maybe/Optional error, exceptions, etc), and get on with it...

[throwaway34241]

Do you think Go's developers and users are simply unaware of exceptions, optionals etc? Or is it that the trade offs that they made aren't net positive for most use cases? Even if the second was true, that isn't necessarily a bad decision; since C# continues to exist, there may be more use for a language targeted to some niche than just a copy of C#.

I've used C# and Go extensively and like both languages. In some big ways they are similar: garbage collected, (fairly) fast compile times, large ecosystems, good tooling (if you include the JetBrains tooling for Go), built in lightweight concurrency, etc. It's not surprising people compare them.

For the areas where they differ, Go in general is more explicit and more low level. Handling errors as return values instead of exceptions is more typing, but I find it easier to check that error handling has been done correctly in my own code and in third party libraries. Instead of the class/struct dichotomy pointers are explicit and any type can be used as a value type (there's also more flexibility in using Go types with unmanaged memory, and the ability to take interior pointers). The way interfaces are implemented they can be used in more places without boxing.

C# has generics but I've run into frustrating limitations with them, for example not being able to write numeric code that works with either 32 bit or 64 bit floats. Go's generics are currently limited to some built in types but the proposals being iterated on seem like they'll be more useful to me than C#'s implementation if they make it into the language.

Other things: Go has a single concurrency story so the ecosystem isn't divided into sync/async worlds, is a less complex language overall, and is a bit less verbose aside from error handling (no public static void etc). Overall I probably prefer Go, but I like C# also and could easily imagine projects where it might be a better choice especially in areas where the lower level aspects of Go aren't useful.

Reading HN, it seems like a lot of people believe that people who use Go (and even the language designers) are simply ignorant. I'm open to the possibility, but can you flesh it out for me a little bit more? What am I missing here?