Hacker News new | past | comments | ask | show | jobs | submit login

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'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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: