3 ms·
I can see how using Go's GC reduces the codebase. But I don't see how that reduces binary size. Compiled Go programs include a Go runtime in their binary, cor
by RetroTechie 3y ago
I can see how using Go's GC reduces the codebase.
But I don't see how that reduces binary size.
Compiled Go programs include a Go runtime in their binary, correct? (statically linked).
So if Go program uses Go's builtin GC, that GC wouldn't be part of the program code, but would be part of the runtime that it's packed with in the binary, right?
In essence replacing [GC in Go program part of the binary] with [GC in Go runtime part of the binary].
I mean, I can see the advantage(s) there. But reducing binary size doesn't seem to be one of them. Unless you count [Go program using its own GC + the one in Go runtime] vs. [only the one in Go runtime].
It's still a (read: at least 1) GC included in the binary.
- skitter 3y agoYou're right, but that's what's meant - using the Go GC vs also implementing a custom one.
- coldtea 3y ago>But reducing binary size doesn't seem to be one of them. Unless you count [Go program using its own GC + the one in Go runtime] vs. [only the one in Go runtime] Yes, of course that's what they mean. Not having 0 code for GC altogether, but just using the GC that you already have, and is required overhead, as opposed to implementing another and having both.