4 ms·
From TFA: > An important factor in reducing the size of the codebase and executable is that Jacobin relies on Go’s built-in memory management to perform garbag
by nightowl_games 3y ago
From TFA:
> An important factor in reducing the size of the codebase and executable is that Jacobin relies on Go’s built-in memory management to perform garbage collection, and so it contains no GC code.
I don't see how you can't see it.
- RetroTechie 3y agoI 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.