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 3 hours ago | parent | next [-]

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

	▲	MarkSweep 2 hours ago \| parent [-]
		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 2 hours ago | parent | prev [-]

> 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 2 hours ago | parent [-]

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

▲

cloudfudge an hour ago | parent [-]

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

	▲	ameliaquining 28 minutes ago \| parent [-]
		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...)