To make the comparison a little more valid, we can strip symbols with a compiler flag and pass the result through `upx` for to build a stripped, compressed binary at only 300Kb:

`go build -o /tmp/hello -ldflags='-s -w' /tmp/hello.go && upx --brute /tmp/hello`.

Also worth noting that the author is incorrect about the Avian example being self-contained--it dynamically links against 4 libraries (on OS X, anyway) while the Go version links against zero.

Further, the Avian example is broken on OS X (the GUI loads, but immediately freezes).

Of course, the applications aren't doing the same work, so comparing the binary sizes is silly. I just wanted to point out that avian's tricks are readily accessible for Go programs as well.

> it dynamically links against 4 libraries (on OS X, anyway) while the Go version links against zero.

And how exactly does that work out on platforms that don't have stable syscalls?

On Mac, Go breaks the rules and hardcodes syscall numbers anyway.

On Windows, Go dynamically links to kernel32.dll and friends.

So in theory Go programs can't be considered reliable across multiple versions of macOS without recompilation then?

It only matters if it also happens in practice.

All forwards-compatibility issues were only "theoretical" issues that didn't "matter in practice" until a new release of the platform came out and suddenly they did.

It does happen in practice:

https://github.com/golang/go/issues/16272

It's not using Swing.

My mistake; what's it using? Native UI?

It's using SWT which is a sort of unholy combination of the disadvantages of both native and cross-platform ui.

It does load fast though. I played with a little SWT app and it was amazing to to see a Java GUI that would launch with no perceivable delay.

Zig[1] hello world is a 13 KB static executable:

    const io = @import("std").io;
    
    pub fn main() -> %void {
        %%io.stdout.printf("Hello, world!\n");
    }

It could be a lot smaller, but I'll have to fix an LLVM bug[2] or two.

For comparison (these are all with full optimization and stripped):

* Go: 1,006 KB, static executable

* Rust: 411 KB, links to libdl.so, libpthread.so, libgcc.so, libc.so

* C: 6 KB, links to libc.so

* C++: 6 KB, links to libstdc++.so, libc.so

* Nim: 26 KB, links to libdl.so, libc.so

* D: 546 KB, links to libpthread.so, libm.so, librt.so, libdl.so, libgcc.so, libc.so

libc.so is 1.9MB. libstdc++.so is 1.5MB.

[1]: http://ziglang.org/

[2]: https://bugs.llvm.org/show_bug.cgi?id=27610

And Nim can be a lot smaller too https://hookrace.net/blog/nim-binary-size/

That's pretty obvious as the interpreted code has the entire library base of the runtime.

To show this to the extreme, here's a "hello world" that's less than 30 bytes:

    #!/bin/sh
    echo Hello world

The program compared to "Hello World" in Go is not "Hello World", it's a SWT GUI widget demo.

"You know, when we had our first C++ compiler, at AT&T, I compiled 'Hello World', and couldn't believe the size of the executable. 2.1MB" -- Barney Soupstuck, 1998

My first Modula-2 program back in the late 80s compiled (on a Sparcstation) to 94kB. I thought that was outrageous.

Eh? From the article:

> It’s not a trivial Hello World app at all, yet it’s a standalone self-contained binary that clocks in at only one megabyte. In contrast, “Hello World” in Go generates a binary that is 1.1mb in size, despite doing much less.

I wrote a jvm-to-go cross compiler and just trying to compile some of the Java stdlib takes forever in Go. Now, this is probably mostly due to how I solve thing like polymorphism and inheritance, but it goes to also show the different approaches to the stdlib. Go eliminates a ton of unused code because their stdlib doesn't have a ton of circular references that're hard to break.

If BC concerns weren't a thing, a fresh Java stdlib would remove a ton of the size complaints.