5 ms·
> Worse, native CPU code is a lot larger than JVM bytecode. > > [Goes on to show how Hello World is just 1 MB, which is smaller than Go's Hello World]
by dom0 10y ago
> Worse, native CPU code is a lot larger than JVM bytecode.
>
> [Goes on to show how Hello World is just 1 MB, which is smaller than Go's Hello World]
- pvg 10y agoThe program compared to "Hello World" in Go is not "Hello World", it's a SWT GUI widget demo.
- doodpants 10y agoEh? 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.
- mhh__ 10y ago"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
- Tloewald 10y agoMy first Modula-2 program back in the late 80s compiled (on a Sparcstation) to 94kB. I thought that was outrageous.
- koolba 10y agoThat'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
- weberc2 10y agoTo 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.
- pvg 10y agoIt's not using Swing.
- weberc2 10y agoMy mistake; what's it using? Native UI?
- dom0 10y ago> 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?
- pcwalton 10y agoOn Mac, Go breaks the rules and hardcodes syscall numbers anyway. On Windows, Go dynamically links to kernel32.dll and friends.
- penpapersw 10y agoSo in theory Go programs can't be considered reliable across multiple versions of macOS without recompilation then?
- 10y ago
- kodablah 10y agoI 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.
- AndyKelley 10y agoZig[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/ http://ziglang.org/ [2]: https://bugs.llvm.org/show_bug.cgi?id=27610 https://bugs.llvm.org/show_bug.cgi?id=27610
- dom96 10y agoAnd Nim can be a lot smaller too https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/