Oh hey, author here! The follow-up was discussed here: https://news.ycombinator.com/item?id=31112273

That was a fun read. Do you think you'd have figured it out without a debugger on the target?

Hard to say in hindsight - I might've looked at the unicows documentation closer again anyways.

I'm more surprised by the fact that it's nearly 200KB for a Hello World in a non-GC native language.

Rust bundles its standard library, instead of having it in MSVCx.DLL. The println macro pulls in a lot of fancy formatting machinery. It also panics when stdout is closed, which pulls in panicking, debug print, and unwinding.

This is a one-time cost per executable. Projects for embedded systems typically disable these features to avoid the costs.

I created more complex programs with a much smaller size (without special optimizations) - up to date windows though

For embedded work, you can take steps to make your Rust binaries much smaller. I know people who do demoscene in Rust. You can take that Hello World down to triple-digit bytes if such a thing matters for your use case.

A useful reference: https://github.com/johnthagen/min-sized-rust

A couple of reasons of the top of my head:

- msvcrt linked statically

- even when disabling debug and panic unwind, Rust includes the unwind tables in the binary

- unicows import library linked

The interesting part is when I do this:

./hello > /dev/full

Does it fail silently? Loudly? Does it pretend everything went well? And most importantly, does it do what it _should_ do, whatever that is?

You get on stderr:

    failed printing to stdout: No space left on device (os error 28)

and if stderr is borked, you still get an exit code 101 (Rust's code for a panic).