[codegeek]

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]

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

[MarkSweep]

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

[cloudfudge]

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

.Net can compile to a self-contained binary: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

[cloudfudge]

That isn't truly self-contained. It still relies on libc.

[jaen]

Nah. Go also relies on libc if you do anything non-trivial, like look up a the IP address of localhost.

    $ go build -o hello main.go
    $ file hello && ldd hello
    hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go
        linux-vdso.so.1 (0x00007f9c7b404000)
        libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c7b1ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9c7b406000)

[cloudfudge]

Lol well I don't know what the trigger is for pulling in libc there, because I've built massive scale services that did a lot of nontrivial stuff and then the deployment was a single-binary docker container that did not have libc. The only thing needed to be put in the container was a directory full of root certs so it could do TLS.

(full disclosure, I don't think I ever had my service look up the address of localhost)

edit: seems like you probably have CGO_ENABLED=1, which is now the default and will cause simple networking things to use libc. Set CGO_ENABLED=0 and you won't have libc.

[jaen]

Yeah, I'm fully aware, no point in "works for me"-ing this.

CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.

[ameliaquining]

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

[cloudfudge]

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]

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.

[potato-peeler]

I suppose you are missing the point. Go had support for self contained binaries since its introduction in ~2009. This was not the case with dotnet, if i am not wrong.

But nevertheless , if any language provides something like that, win-win for entire ecosystem.

[cloudfudge]

Agreed. The fact that .NET has a way to do true static linking is great and I didn't know it existed. The fact that they apparently think it's a weird and undesirable thing is less great and would make me worried that they're going to undermine the ability at some point. Golang has had this ability since way back and they think it's a strength.