And your point is completely wrong. It makes no sense for a language to by default optimize for the lowest possible binary size of a "hello world"-sized program. Nobody's in the business of shipping "hello world" to binary-size-sensitive customers.

Non-toy programs tend to be big and the size of their code will dwarf whatever static overhead there is, so your argument does not scale.

Even then, binary size is a low priority item for almost all use cases.

But then even if you do care about it, guess what, every low level language, Rust, C, whatever, will let you get close to the lowest size possible if you put in the effort.

So no, on no level does your argument make sense with any of the examples you've given.

> My point was that many programmers have no conception of much functionality you can fit in a program of a few megabytes.

Many of my real-world Rust backend services are in the 1-2MB range.

> Here is a pastebin[1] of a Python program that creates a "Hello world" x64 elf binary.

> How large do you think the ELF binary is? Not 1kb. Not 10kb. Not 100kb. Not 263kb.

> The executable is 175 bytes.

You can also disable the standard library and a lot of Rust features and manually write the syscall assembly into a Rust program. With enough tweaking of compiler arguments you'd probably get it to be a very small binary too.

But who cares? I can transfer a 10MB file in a trivial amount of time. Storage is cheap. Bandwidth is cheap. Playing code golf for programs that don't do anything is fun as a hobby, but using it as a debate about modern software engineering is nonsensical.

No disagreement here! Just curious how big the impact of debug symbols was and wanted to share my findings.