Hacker News Reader

Comment by nwmcsween | Hacker News Reader

Not trying to be inflammatory but has the pclntab taking ~30% for binary size been fixed yet? IMO it's a pretty severe design choice.

View on HN

> IMO it's a pretty severe design choice.

I don't think that's true, otherwise it would've been fixed already. For the main use case of Go (https://go.dev/blog/survey2022-q2-results), APIs and web services it just doesn't matter if the binary is 1MB or 30MB. Unless you are working on some embedded systems where space is scarce I don't see it as a big issue.

1MB vs. 30MB is the difference between:

- Pull the prod image to my laptop in ~1 sec vs. pull the image in 10ish seconds

- CI build and push the image instantly vs. ~2-3+ seconds

- Long-term (1y+) retention of per-pipeline/push artifacts vs. per-branch/tag artifacts.

- All images in each node's cache vs. 50% of images in each node's cache.

Yeah, I don't really give a shit about the 30MB once it's out there. But there's also all the steps to get it / keep it out there.

No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.

do you know how things like tzdata and locale are handled in a single Go executable docker image ?

tzdata, at least, can be embedded in your binary: https://pkg.go.dev/time/tzdata

You can build a much smaller 0 dependency binary in Rust/C so what's the value prop for Go here?

The value prop is it's not Rust or C?

Sounds like a sidegrade to be honest, not worth the massive bins

The single biggest silver bullet for provable bug reduction that has ever been invented: GC.

Perhaps the Rust burrow-checker will prove to be the second silver bullet for bug reduction, but for now, the only thing that has ever been invented in programming language design that provably reduces the amount of bugs in an application is having a GC (not types, not getting rid of null values, not monads or other HKTs, not CSP).

That's not true. I've warmed up a lot to Go over the last 6 months. I enjoy writing it and I find it useful. However, it still frustrates me that the base binary size is something like 15 MB. That being said, if you add a bunch of static linking into a C++ or Rust app the sizes may be comparable. But because Go frontloads so much stuff with it's forced static linking the binary sizes can become unruly.

You can imagine transfer costs in a CDN, storage, etc all mattering in the edge cases. Not everyone would have this problem but if your Go app is sufficiently popular and you need to distribute it you may see this as a problem.

where is that issue listed?

https://github.com/golang/go/issues/36313

Ah that seems to be the issue some CockroachDB guy complained about. I don't think its high priority for Go team.

The CockroachDB guy didn't understand what he was doing. There's a refute from Russ Cox here: https://news.ycombinator.com/item?id=26834128

Yes, I remember that, didn't want to link RSC's comment to avoid more angry replies here.

Reply on news.ycombinator.com