3 ms·

I love Go. But I prefer .NET for web development that also compiles to a binary and has a great ecosystem of libraries and packages. Go is great if standard lib

I love Go. But I prefer .NET for web development that also compiles to a binary and has a great ecosystem of libraries and packages. Go is great if standard library works (and it can for many cases) but when you need to start looking into non standard libraries, Go can hit limitations. For example, to build a full production web application with database in Go, there is no great out of the box migration tool. There are some good 3rd party libraries of course but compared to something like EFCore in .NET, they don't come as close. For me, it is now .NET and then Go. Of course, I use Go when just doing a lot of non web stuff as well.

bronlund 5mo ago
Comparing Go and .NET is like comparing a Honda with an aircraft carrier with wheels.
- MarkSweep 5mo ago
  Eh, at least for people consuming .NET apps compiled with NativeAOT, the experience is similar. Applications can be compiled as a single file with no dependancies. A hello world in .NET is half the size of one in Go: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizegame
cloudfudge 5mo ago
> that also compiles to a binary "compiles to a binary" is not a useful criterion. The criterion Go is winning on is "compiles to a single, completely self-contained binary," meaning it does not depend on libc or any external runtime. You can't say that about .NET. You can't say that about damn near any other programming language. It's extremely rare. The fact that .NET uses a binary packaging format is, like... well ok, so what?
- kevinmgranger 5mo ago
  .Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8 https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
  - cloudfudge 5mo ago
    That isn't truly self-contained. It still relies on libc.
    - ameliaquining 5mo ago
      You can make it statically linked using musl. (This is underdocumented because Microsoft thinks it's usually a bad idea: https://github.com/dotnet/sdk/issues/37643#issuecomment-1873704740 https://github.com/dotnet/sdk/issues/37643#issuecomment-1873...)
      - cloudfudge 5mo ago
        Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be and do not consider that a liability but a strength.
        ameliaquining 5mo ago
        I agree that this is the best approach if your organization is technically mature enough to be on top of it. I do have some sympathy for Microsoft here because they have to ship one set of safe defaults for all the different distribution and deployment setups that are out there, and statically linking your TLS library has the more dangerous failure mode (shipping a known-vulnerable version) if you don't have a rock-solid continuous-delivery setup, which Microsoft has no way of knowing whether is the case or not. I do think they could formally document this with a "don't enable this unless you've got monitoring set up for vulnerable native dependencies and can quickly ship a new build" security warning, though.
        cloudfudge 5mo ago
        Yes, totally agreed that for a LOT of organizations, relying on a system dependency that will likely get upgraded independent of your service is probably the simpler way to go and the way to make sure your TLS implementation stays current. But when you're building tier zero services that must control their dependencies like their lives depend on it, the opposite approach can be quite beneficial, and I don't need Microsoft telling me I'm doing it wrong because I'm not in the 99% use case.

bronlund 5mo ago

Comparing Go and .NET is like comparing a Honda with an aircraft carrier with wheels.

MarkSweep 5mo ago
Eh, at least for people consuming .NET apps compiled with NativeAOT, the experience is similar. Applications can be compiled as a single file with no dependancies. A hello world in .NET is half the size of one in Go: https://github.com/MichalStrehovsky/sizegame https://github.com/MichalStrehovsky/sizegame

cloudfudge 5mo ago

> that also compiles to a binary "compiles to a binary" is not a useful criterion. The criterion Go is winning on is "compiles to a single, completely self-contained binary," meaning it does not depend on libc or any external runtime. You can't say that about .NET. You can't say that about damn near any other programming language. It's extremely rare. The fact that .NET uses a binary packaging format is, like... well ok, so what?

kevinmgranger 5mo ago
.Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8 https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
- cloudfudge 5mo ago
  That isn't truly self-contained. It still relies on libc.
  - ameliaquining 5mo ago
    You can make it statically linked using musl. (This is underdocumented because Microsoft thinks it's usually a bad idea: https://github.com/dotnet/sdk/issues/37643#issuecomment-1873704740 https://github.com/dotnet/sdk/issues/37643#issuecomment-1873...)
    - cloudfudge 5mo ago
      Oh that's good to know. I happen to think Microsoft is chasing a bad philosophy with that declaration, and there is no more danger in statically linking ssl if you're continuously rebuilding and deploying your statically linked scratch image, but then again, the Microsoft approach to a lot of things isn't what I want in my datacenter. To each their own, I guess. I happen to love how self-contained Go programs can be and do not consider that a liability but a strength.
      - ameliaquining 5mo ago
        I agree that this is the best approach if your organization is technically mature enough to be on top of it. I do have some sympathy for Microsoft here because they have to ship one set of safe defaults for all the different distribution and deployment setups that are out there, and statically linking your TLS library has the more dangerous failure mode (shipping a known-vulnerable version) if you don't have a rock-solid continuous-delivery setup, which Microsoft has no way of knowing whether is the case or not. I do think they could formally document this with a "don't enable this unless you've got monitoring set up for vulnerable native dependencies and can quickly ship a new build" security warning, though.
        cloudfudge 5mo ago
        Yes, totally agreed that for a LOT of organizations, relying on a system dependency that will likely get upgraded independent of your service is probably the simpler way to go and the way to make sure your TLS implementation stays current. But when you're building tier zero services that must control their dependencies like their lives depend on it, the opposite approach can be quite beneficial, and I don't need Microsoft telling me I'm doing it wrong because I'm not in the 99% use case.