4 ms·
Perhaps functional chunks could be excluded from the final emitted binary when they're unused / unreachable from main? How hard would it be to check the AST fo
by jaytaylor 5y ago
Perhaps functional chunks could be excluded from the final emitted binary when they're unused / unreachable from main?
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).
- JulianMorrison 5y agoThe GC needs to mess with and start and stop and throttle threads. The threads resize their stacks and that needs to talk to the GC. System calls park and restart threads. And so forth. If you use any of it you'd need all of it.
- jaytaylor 5y agoYes, the idea is if you want to use X (e.g. the GC), it comes with the binary. Otherwise exclude 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.
- Kwpolska 5y agoHere’s the classic story of when code can live without GC: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... A very basic “Hello world” could also be GC-less and just let the OS reclaim all memory when it terminates.
- JulianMorrison 5y agoYes, I understand the idea, the point I'm making is that the runtime is a monolith, it can't be split because each piece has necessary and irreducible connections to the other pieces.
- jaytaylor 5y agoAh, gotcha. Thanks for patiently clarifying :)