That seems a bit extreme
> Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser
I'm still on board
So why waste the effort putting in a code path to disable these things except for some philosophical ideal?
Code in Asm or C if you need a hello world that can fit on a floppy disk, you're not really doing anything substantial anyways...
There's plenty of acceptable middle ground between Go binaries using 2mb minimum and full electron apps eating your ram.
Not on embedded.
TinyGo supports it, but they built a new compiler to support that use-case.
> TinyGo brings the Go programming language to embedded systems and to the modern web by creating a new compiler based on LLVM.
> You can compile and run TinyGo programs on over 60 different microcontroller boards such as the BBC micro:bit and the Arduino Uno.
> TinyGo can also produce WebAssembly (WASM) code which is very compact in size. You can compile programs for web browsers, as well as for server and edge computing environments that support the WebAssembly System Interface (WASI) family of interfaces.
I'm not so sure about that. A lot of embedded systems software works well without allocating any memory at runtime at all. Particularly microcontroller programs. The first version of Virgil targeted AVR (via codegen to C) and did exactly this; allocate all data structures up front, at compile time, and then bake them into the binary. This is still common in realtime systems.
No dynamic memory allocation = no garbage collector, no non-deterministic allocation/deallocation, no write barriers, no out-of-memory possibilities, no fragmentation. For a surprisingly large class of programs, this is a great situation!
> So why waste the effort putting in a code path to disable these things except for some philosophical ideal?
Virgil in particular, does the opposite; it only includes what the program uses. The analysis starts with nothing and then brings in things called and used from main, tracing through those new things, etc, until the transitive closure is included. Unreachable code isn't even seen, except by the parser and semantic checker, so it doesn't get included. Although, admittedly, the GC is a little special in that a single allocation in the program will drag in most of it. And most programs accept command-line arguments, which the default runtime boxes up into an array of strings for "main()", so most programs do end up with the GC included. You can turn that off with a flag or by modifying the runtime startup code (e.g. squirrel away the arguments array pointer and count, pass null to "main()", and parse the arguments as raw pointers without allocating. (but yuk.)
I know you know this already, but your statement is a little too broad. Those problems all still exist, but are greatly reduced. Data structures still need to be compacted, caches evicted, scratch space cleared, etc. It is just that one class of intractable issues gets removed when dynamic memory allocation goes away.
On a side note, have you seen this? https://github.com/udem-dlteam/ribbit https://www.youtube.com/watch?v=A3r0cYRwrSs an extremely compact VM for a version of R4RS.
It's like, yes, if you turn off the A/C in your muscle car, you'll technically get a few extra horse power.
But past some philosophical ideal of squeezing out every bit of horse power you can, it has a negligible effect on the operation of the car.
Now if you're working on a weed wacker engine or something, yeah that would matter. But you wouldn't pick a giant beefy engine and expect it to work as well as a tiny lightweight one.
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.
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.
There are plenty of embedded systems that have <= 1mb of memory. E.g. a popular one is Teensy (https://www.pjrc.com/store/teensy40.html).
`fmt` is (or was) a big one in every sense of the word, and why using the `print` and `println` builtin functions was sometimes a workaround (probably still is): a few years back, converting a `fmt.Print` call to `print` would save you a cool megabyte (if that was the only cause for importing fmt obviously).
I've always expected that was a major reason for the Go compiler being so anal about unused import, it's essentially making the user perform DCE.
How hard would it be to check the AST for a go program's usage of channels, goroutines, etc at compile time? As these are features not used by the go language itself, it seems nearly trivial (no jit or other super dynamicism).
If you use any of it you'd need all of it.
I'm proposing splitting the functional blocks into distinct pieces and including only what is actually needed in the final binary.
For the case of the GC, if your go program somehow avoids all allocations (wtf??? Empty main perhaps - a seemingly stupid case), perhaps it could be excluded.
A very basic “Hello world” could also be GC-less and just let the OS reclaim all memory when it terminates.
Not to me, I would have done the same.
And I tend to look at the binary size of simple programs to get a first taste of the style of tech I am looking at.
Bloated binaries and slow compilation time are red flags in my book, I use them as simple heuristics to avoid losing too much time.
I know it is not perfect, but it is fast and simple, like all good heuristics.
People do low-commitment exploration of new tech all the time, perhaps offhandedly download some new language compiler to see what all the fuss is about. Even a modestly negative experience can easily tip the scales for them to lose interest and go do something else.
Optimising for size is such a waste of time in this day and age. I know I would rather choose a 5 MB statically linked binary than a 5 KB dynamically linked one, because they take pretty much the same amount of perceived time to transfer over the internet, yet the smaller file might take more of my time because I need to find and install missing dependencies.
On the list of priorities for language developers, size optimisation is towards the bottom, unless we're talking about embedded but we aren't.
Except in very specific context, shaving bytes is pointless, and a few kilobytes are barely relevant.
But in the real world we're often talking about several orders of magnitude differences.
I would still accept a Hello World that is around 100Kbytes, but not an order of magnitude more.
And I am talking about statically linked app, this is an other subject but I tend to think that dynamically linking is way overused and rarely justified.
As far as whether size matters - it really depends. Some parts of the world are still mostly on dialup (or very slow mobile).
I guess we all have some set of scope creep that we take as OK. ABI compliance for some, GC or other niceties for others, and then there is anything node/electron based.