4 ms·
> Is it really though? 2mb is practically nothing on modern machines. In general, I agree actually. I think hemming and hawing over duplicated shared libraries
by AnIdiotOnTheNet 5y ago
> Is it really though? 2mb is practically nothing on modern machines.
In general, I agree actually. I think hemming and hawing over duplicated shared libraries in particular makes no sense for most modern systems. Still, 2MB is a pretty damn big overhead to put on every binary the way Go does. Not that it isn't a considered trade off or anything, I'm just saying.
> And full-fat debug should have as much info as it can, why optimize it unless you're spitting out 400+mb binaries or something crazy.
That's my point: there's no optimization in the full-fat debug and it does contain everything it can and it's still a little more than half the size of a completely empty Go binary. 2MB is huge. For the ReleaseFast version all I did was tell the compiler to optimize for speed and otherwise put no effort into making anything size efficient.
- spicybright 5y agoI'm still not really getting why "huge" matters though, unless you're doing very small embedded work. Which I'd argue Go isn't a great choice in the same way that running full linux on a limited microcontroller is not a good choice. Every systems language shouldn't have to over complicate it's run time to squeeze kilobytes out if 99% of use cases are running on modern personal computers. (C or TinyGo, or a variety of languages are better suited for embedded) Like, yeah, 5 cents is huge compared to 1 cent, but we're dealing in hundred dollar bills here.