dank (Jan 28 2023 at 13:21): dank (Jan 28 2023 at 13:21):hello world with basic_cli and --opt-size is like 102M, stripped 19M which is kind of a lot.
I assume most of it is platform right?
So what else can be done to optimize size
And would it be possible in the future in compilation to strip down stuff from platform that isn't used by the application
Anton (Jan 28 2023 at 13:46):I think @Brendan Hansknecht looked into this recently
dank (Jan 28 2023 at 13:49):i also wonder about statically linked executables
rn it links with a bunch of stuff. is it planned to offer completely statically linked binaries
Anton (Jan 28 2023 at 13:54):is it planned to offer completely statically linked binaries
Yes indeed, static linking would make it work out-of-the-box on NixOS
dank (Jan 28 2023 at 14:03):would it be a compiler flag like zig's -static or in general you wish to output only static?
Anton (Jan 28 2023 at 14:22):good question, l'll look around a bit to see what our options are
Anton (Jan 28 2023 at 15:39):Whenever possible I think we should use "config" files for the platform. So for rust this could be done with Cargo.toml and .cargo/config. I don't have much zig experience but I think 'build.zig' can be used for that?
For c platforms a roc flag like --platform-build-flags="" may be the most appropriate.
Brendan Hansknecht (Jan 28 2023 at 16:29):Once we get the platform building logic out of the compiler itself, and into some sort of config in the platform, roc will have no way to control this. It already can't really effect this. If the platform is static roc will end up generating a truely static library. That said, we may have to jump through some more surgical linker hoops to make this fully work.
Brendan Hansknecht (Jan 28 2023 at 16:30):Fundamentally, the surgical linker relies on the platform generating an executable where just the roc app is dynamically linked. Then we patch it up and remove that dynamic linking.
Brendan Hansknecht (Jan 28 2023 at 16:33):As for the 102M basic_cli, i would have to look back over things to remember the exact cause, but i think it is a bug specifically related to rust hosts that ends up making them very bloated. I think the surgical linker can work around this, but we still have the issue because we support both the surgical and legacy linker. Don't exactly remember the details.
Brendan Hansknecht (Jan 28 2023 at 16:34):Oh, also with the new plan for effects, i think it should also help a lot.
dank (Jan 28 2023 at 17:51):Brendan Hansknecht said:
Oh, also with the new plan for effects, i think it should also help a lot.
what's the new plan for effects
Brian Carroll (Jan 28 2023 at 17:57):Richard outlined the plan at a meetup recently. Luke hosted the meetup and shared a recording in this thread:
https://roc.zulipchat.com/#narrow/stream/303057-gatherings/topic/Roc.20Online.20Meetup.20Jan.202023
Brian Carroll (Jan 28 2023 at 18:02):In brief:
The Roc app sends an effect to the platform as a value containing a callback. The callback is a "continuation" that returns next effect. Keep going like this till the program is finished.
Brendan Hansknecht (Jan 28 2023 at 18:29):The big reason why this should help with binary size is that we won't have to fight with the platforms dead code elimination. It will now be more directly managing all functions that roc could interact with. With the current system, roc essentially uses ffi to directly call platform functions instead. This means the platform needs to keep all of those functions around even if it would normally dead code eliminate them. I think in rust, we fully turn of dead code elimination for platforms. That should be fixed with this update.
dank (Jan 28 2023 at 18:41):ah that's clever
Last updated: Jul 05 2025 at 12:14 UTC