Hacker News Reader

Comment by msla | Hacker News Reader

Go and .Net languages aren't in the same space unless you can build native static binaries with .Net tools.

Unless and until the "installation strategy" for a .Net program is "copy the binary to the target system" they aren't going for the same kinds of people. That's OK, diversity is good, but don't pretend the differences don't matter.

View on HN

Native static binaries are such a small part of what defines Go. Go is absolutely a competitor in the jvm/.net space. C# and Java are its closest competitors since they're all performant, statically typed, and garbage collected.

Compiling to binaries is an advantage but I can guarantee it's not why most people use Go.

Single file deployment has already existed in the last version (.net 5.0), is better in the current version (.net 6) and set to get even better in the upcoming releases.

Also the rise of containers has obviated much of the issues around deployment and I've never seen "native static binaries" be a requirement for choosing a language stack.

I wrote a little command line tool in C# a couple of years ago. I'm lazy, I just copy it into the working directory and run it there.

This is pretty much the case with .net now. I build zero install systems that carry the appropriate framework with them.

Does the target system need a CLR interpreter already installed?

No, it gets dumped in the directory when you build a stand alone system. Ive used this where I am deploying things for customers who don't want to install extra stuff on their servers as an example.

Super handy for customers who insist on running ancient versions of windows server too.

No. You can also build a single file like in go. Its set to be even better on .NET 7

Reply on news.ycombinator.com