Note: I don't actually believe a 30MB static binary is a problem in this day and age
Depends what that 30MB does, or how much of it is actually needed - it's less of a problem if all those bytes are used in some form or another, than if a significant portion of them are "dead code" that is never used and only serves to take up space in memory, on disk, and in communications channels whenever it's transferred somewhere.
and I would not trade (build time | complexity | performance | debug-ability) for it
On the contrary, smaller binaries are usually going to be better at all of those, except perhaps "debug-ability" if you keep the debugging symbols in the same file.
>> Note: I don't actually believe a 30MB static binary is a problem in this day and age
> Depends what that 30MB does, or how much of it is actually needed [....]
Moreover, let's consider a CLI tool suite. Dozen little tools, each doing
perfectly what it was designed to (think of coreutils, util-linux, sysstat,
binutils, or iproute2). Such a suite suddenly weighs 300MB, more than X.Org or
PostgreSQL (or the two combined). Does it really do more than any of these two
to justify the size? I doubt it.
The availability of huge disks has probably skewed the perception of sizes to some extent. 300MB is more than sufficient for an entire operating system, including a GUI and several dozen CLI tools. A full install of Windows 98 was 175MB.
On the other hand, internet speeds have not increased quite as dramatically, so we can still relate with stories of "this app is how big? And it only does what?"
Said this here a few times already but since you mention it: last month I booted a win98 box. The bliss of small binaries. Everything was snappy even on a Pentium 3. Bonus point: enjoying the Turbo Pascal suite (IDE, Compiler) for a total of 800KB. I want to backport crypto, binary hardening some lisp over win98 and live in MB land (pun not intended).
Indeed. Just the other day I was trying (with no luck) to find a simple drawing app for Android (something like Paint on windows) that was less than 18 MB. Seriously, that sort of app should not need huge executables like that.
The amd64 Linux version of Terraform [1] unzipped uses 739 Megabytes on disk (`du -hc`). It is a collection of CLI tools, or one CLI tool that wraps many provider-specific tools (providers such as aws, azure, etc.).
I noticed this recently when trying to upload a container image that happened to include Terraform.
Eh, 300mb, who cares? There's plenty of disk space and usually plenty of bandwidth. If it's becoming a problem for you then sure, do something about it, but I don't think 300mb is a priori a problem.
Depends what that 30MB does, or how much of it is actually needed - it's less of a problem if all those bytes are used in some form or another, than if a significant portion of them are "dead code" that is never used and only serves to take up space in memory, on disk, and in communications channels whenever it's transferred somewhere.
and I would not trade (build time | complexity | performance | debug-ability) for it
On the contrary, smaller binaries are usually going to be better at all of those, except perhaps "debug-ability" if you keep the debugging symbols in the same file.