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