3 ms·

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

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.

shantnutiwari 6mo ago
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 6mo ago
  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 6mo ago
  .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 6mo ago
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 6mo ago
  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 6mo ago
    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
    - xnorswap 6mo ago
      That's quite a rant, but it seems like it's from experience with the old times. For the last decade or so it's been a completely different story. System.Text.Json is part of the core standard library, the only reason to use Newtonsoft is developing on legacy applications. Visual Studio isn't necessary or even much recommended any more. VSCode or any LSP editor works fine. You don't need to install nuget, any more than you need to install cargo in rust, it's part of the SDK. You can also just edit the csproj in the same way you could edit your TOML file. It's XML, and you just add <PackageReference="" />. You can compile --self-contained to be able to run it somewhere without the runtime installed. .NET has a long history, but almost none of these are actual points of friction in the current year.
pjmlp 6mo ago
I only have one reason, devops ecosystem where Go is expected nowadays, like plugins for something. Otherwise Java, .NET, Typescript (with possible C++ addons).

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.

shantnutiwari 6mo ago

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 6mo ago
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 6mo ago
.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 6mo ago

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 6mo ago
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 6mo ago
  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
  - xnorswap 6mo ago
    That's quite a rant, but it seems like it's from experience with the old times. For the last decade or so it's been a completely different story. System.Text.Json is part of the core standard library, the only reason to use Newtonsoft is developing on legacy applications. Visual Studio isn't necessary or even much recommended any more. VSCode or any LSP editor works fine. You don't need to install nuget, any more than you need to install cargo in rust, it's part of the SDK. You can also just edit the csproj in the same way you could edit your TOML file. It's XML, and you just add <PackageReference="" />. You can compile --self-contained to be able to run it somewhere without the runtime installed. .NET has a long history, but almost none of these are actual points of friction in the current year.

pjmlp 6mo ago

I only have one reason, devops ecosystem where Go is expected nowadays, like plugins for something. Otherwise Java, .NET, Typescript (with possible C++ addons).