Hacker News Reader

Comment by pjmlp | Hacker News Reader

Usually that means you aren't using trimming, .NET speak for dead code removal during linking.

Also remember that standard .NET runtime does a little bit more than Go's runtime, so it might happen that even with trimming, for basic applications Go ends up having an upper hand on file size.

On the other hand, I have had Go static binaries grow up to 200 MB and being require to use UPX to make it manageable, e.g. trivy.

View on HN

You're right. But even with trimming I get around 10x the size of the Go binary

Since I edited my comment, see my additional remarks regarding runtime capabilities, and the counterpoint of big Go binaries.

Also note that triming only works properly if the libraries have taken the effort to be trimmable, as the linker errs on the safe side and won't trim unless certain that it is really dead code, and not called via reflection.

    dotnet publish -c release -p:PublishAot=true

Reply on news.ycombinator.com