I started developing a system from home and when deploying to a VPS for testing and production. Transferring Go binaries was like waiting for a floppy disk to copy due to poor Internet infrastructure. Compression didn't help much.
It turned out to be significantly faster to push to a remote git and have a hook do the build. I think before you look to compress a go binary consider if there aren't other options.
I've been throwing around an idea for a site called "Church of the Byte Savers" or some other silly name based around saving hard drive space and bandwidth. e.g. Dropbox is good because it has LAN sync, whereas OneDrive will send your data around the world just to get it to a second PC on your network.
I like that. I see people preaching how we've become accustomed to large drive space and fast internet and we're just wasting it all out of laziness.
Kind of like the post Muad'dib Fremen that got soft on water discipline.
Thank goodness for multipart uploads, at least.
This gives me the ability to `rsync` them up rather than copy, using its ability to only transfer the pieces of the files that have changed.
We have a ~20MB .war file that I have done this with over airport wifi, and it ended up only transfer a few 10's of KB (maybe 100) between compiles.
I guess I should be thankful I mainly work with text and not images, video or large proprietary file formats otherwise I think I would be out of the game.
My phone is now about 5 times faster than my home Internet for both uploads and downloads but also significantly more variable and expensive. The fibre internet upgrade that was scheduled for last year had the technology downgraded and the rollout delayed due to politics.
It got much less fun when each deploy to the prod server took an hour to complete.
rsync --inplace -vaz sourcefile user@remote:/targetdir/