I can't see any reason this list why I should use Go over C# / .NET.

.NET has almost all these upsides, but with a concurrency model (async/await) that is (now) more transferable to other languages.

▲

pjmlp 2 hours ago | parent | next [-]

I only have one reason, devops ecosystem where Go is expected nowadays, like plugins for something.

Otherwise Java, .NET, Typescript (with possible C++ addons).

▲

shantnutiwari 5 hours ago | parent | prev | next [-]

Agreed-- c# has a lot of these advantages and is a lot easier to write (yes, I know this will depend). Plus it has a much larger ecosystem

The only thing I can think of: I dont think c# can compile as easy to a single executable binary, like Go (or even rust)?

	▲	xnorswap 5 hours ago \| parent \| next [-]
		It's had support for single exe compilation for a while now, although the file sizes can get large without being more careful about dependencies.
	▲	stackskipton 5 hours ago \| parent \| prev [-]
		.Net SRE here, you can do self contained executable but there is some foot guns there and if you are doing containers already, I'd just skip it.

▲

2ndorderthought 4 hours ago | parent | prev [-]

I can see reasons why people don't want to use .NET if Go is available. .NET has its merits but it's bloated, compilation is slow, and I find it's tooling to be really annoying.

For me go is just above c# and both of those are not super high on my list.

▲

xnorswap 4 hours ago | parent [-]

I've never understood what is meant by "bloated", would you mind explaining, so perhaps I could better understand?

If it's "Large standard library", I think that's a selling point. Having anything you need available ( although these days, via optional microsoft.* packages ) helps keep projects consistent between different places.

If it means "Different ways to do the same thing", I can understand that criticism better, and some of that comes with 20+ years of legacy, where the wrong thing was done, and now there's a better way, but a ruthless adherence to backward compatibility means that the old way isn't dropped.

	▲	2ndorderthought an hour ago \| parent [-]
		The .net sdk is like 1gb, go is like 60mb or something. It's annoying when that matters. More so, nothing happens quickly with it's tooling, and the tooling isn't friendly. All of a sudden I can't build my project in vsstudio(also bloated but admittedly optional but may be required depending on where you work). Clean build also fails. So I have to go to the command line and type in dotnet restore, dotnet build, magic it works now. ??? Okay time to install a package because msft has its own packages for things like aspnet but now I want to serialize json. Cool newton soft sounds good. Ah now I need a package manager, I'll install nuget. Oops I need to tweak this weird xml file with lots of options. I press compile I wait 3 minutes to realize there is an error. Okay it builds and looks good in debug mide now I want to send my application to a friend who doesn't have .net runtime... With go it's more like. Okay I automatically have web access from the std lib. I want a framework oh I already have a package manager. Edit my toml. One command done. Time to compile, poof done in 2 seconds. I send the binary to my friend and they run it. I understand some of these are 1 time cost things, but I am requesting you to read between the lines as these aren't examples I am trying to quibble over. The point is the friction that go has focused on removing by being quick and small. It has less legacy cruft but I tried to ignore as much of that as I could. Also keep in mind j am not a big go fan. It's not my favorite language but it is way easier to deal with on a regular basis for me