5 ms·
> And because everything is statically compiled, go binaries tend to be very large. Are you sure it's because they are statically compiled? Not because each b
by slimsag 12y ago
> And because everything is statically compiled, go binaries tend to be very large.
Are you sure it's because they are statically compiled?
Not because each binary has DWARF debug symbols in it so that there are useful stack traces?
> Imagine each binary being 5 mb on average and multiply that by 100.
I don't think it's a factor of 100 times, that seems a bit outrageous.
- rurounijones 12y ago>> Imagine each binary being 5 mb on average and multiply that by 100. > I don't think it's a factor of 100 times, that seems a bit outrageous. I think he means 100 utilities all weighing in at 5mb
- masklinn 12y ago> Are you sure it's because they are statically compiled? Not because each binary has DWARF debug symbols in it so that there are useful stack traces? Removing DWARF information with -ldflags -w reduces the size of the binary by 20%. The binary is 1.8MB originally... $ go build hello.go $ wc -c hello 1806192 hello $ go build -ldflags -w hello.go $ wc -c hello 1408880 hello the rest is pretty much all runtime, the hello world itself should take about 10k, that's more or less the size of the C or dynamically linked Rust versions (Rust also uses static linking by default, and the hello world is 300k in that case)
- f2f 12y agoto see how much the runtime contributes to the size of the binary use an empty main. for hello world you bring in the fmt package which is a relative heavyweight: $ cat > t.go package main func main() {} $ go build t.go $ wc -c t 623280 t $ nm t | wc -l 1029 $ cat > t.go package main import "fmt" func main() { fmt.Println("hello world") } $ go build t.go $ nm t | wc -l 2541