While your point is absolutely true, the rule of thumb in those case is that the growing curve in file size is not linear; while the very minimal executable already brings lots of things it doesn't need, adding functionalities make it grow slowly (since a lot is already there).

Not saying this is not an issue (although it isn't really in most fields, except for things like embedded), but that the 656 KB for "Hello World" is because of the "upfront cost" in binary size.

I have spent sometime developing in Delphi years back, and this was even more true with it (simple hello world GUI app was over a megabyte [create new project and compile], complex GUI app was barely above it).

Plus embedded environments which have problems with an executable weighing 656KB aren't really a good target for .NET, to start with.

If it's truly just a single binary, wouldn't that include the whole GC and runtime system? If so its probably the entire core runtime plus a few bytes to console.writeline a string.

> but considering that a real native "Hello World" binary is <1KB, what's the other 655KB doing?

Language runtime.

You may enjoy this dated blog post to give you a hint why the executable is 656KB, not to mention the runtime and garbace collection overhead:

http://blogs.msdn.com/b/abhinaba/archive/2008/09/15/how-many...

There are larger runtimes.

    # echo 'main = putStrLn "hi"' > hi.hs
    # ghc --make -optl=-static -optl=-pthread hi.hs -o hi
    [1 of 1] Compiling Main             ( hi.hs, hi.o )
    Linking hi ...
    # file hi
    hi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
    # du -hs hi
    10.6M   hi
    # strip hi
    # du -hs hi
    4.4M    hi

This is against musl libc by the way.

Have you seen the size of go executables generally?

If you truly wanted your app to just print out the one line then you could probably pick a different language.

In this case you would only pick .net if you were making something complex enough to warrant the size cost in exchange for the perceived benefits.

I mean comparing it to a raw native binary isn't an apples to apples comparison. What might be better would be comparing it to another VM based language like java / ruby / python / node. Where the size of the app is the scripts + the installed runtime.

Your one line "console.log('hello world!')" node app may be less than 1k but with the size of the node binary added in it becomes more comparable.