I for one, celebrate it, regardless of my dislike for Go's type system.
Every step helping taking C out of the picture is a welcome one.
At least it isn't like Microsoft where not matter what, .NET can't displace COM and C++ role on Windows, and isn't even used on new Azure Kubernetes samples.
I wouldn't mind Go if their executables didn't take hundreds of megabytes to do something a C/C++ executable could do in less than 2 megabytes.
There are a bunch of executable size issues languishing on their issue tracker and from what I understand it has to do with how some core features of the language are implemented that causes a combinatoric explosion of entries in a table in the executable. They also made an adjustment to stop compressing that table, which makes sense from a startup time perspective but there are also no levers I can pull to compress the table or disable the feature.
.NET executables have the same issue but I can always dynamically link them against a single runtime.
Funnily enough, .NET's NativeAOT took the opposite route and various tables have dehydrated form in the binary which will be hydrated at startup (with the size wins observed up to 30-35% depending on publish contents)
If you're interested, here's the PR history for the feature:
UPX doesn't always work in the cases where I've had this issue before. There was one application that was approaching 100 megabytes for what amounted to a really high-quality SSH bastion that I tried to use once. UPX got it down to about 30 megabytes, which was great, except that UPX needed to unpack the entire thing into memory to run. On the system I was trying to load this on I only had 128 megabytes of RAM so that size made it a non-starter for me. We do have a Go program to manage our CA certificates that uses UPX but we run it once during boot so it's much easier to manage.
I actually think being able to optionally dehydrate the tables and compute them at startup would be a big win for Go executable size to the degree that it might be a contender in the kinds of systems I work on.
Yes, this exact reason is why I'm not using UPX either. But it is useful when the conversations eventually devolve into binary size golfing ;) (ironic, I think NativeAOT does really well as of .NET 8 in this department).
I'm curious, what are the dependencies of that said Go program for it to take 100 MiB? Can't imagine a .NET (AOT or trimmed self-contained JIT) binary taking this much unless it is a GUI application.
