Hi all! Is it generally considered a bad practice to pass a large record from the platform as an argument into the main app function? And calling that main function multiple times?
I'm toying around with a game idea, and want the platform to call into the apps update : State, Action -> State
function. Every time there is an input (keypress on terminal, etc), said input would be converted to an Action
and would call into update
to see how it affects the game state. I assume that means that the inputs State
and Action
would be allocated on the heap, and have noticed significant effort in some of the examples to avoid doing exactly that. Is this a bad idea, and if so how should I go about it instead?
at least today, records and non-recursive tags are fully on the stack, always
under the hood big records are passed as pointers to this stack memory
so, I think it should be fine?
Ok great, and there isn't a significant amount of overhead from the platform calling into the app multiple times? From what I've seen in the example they all only call into it once
examples*
no, it's just a function
the existing examples don't need the repeated calls, but more complex examples will
it's something we want to support for sure
Okay awesome, thanks for answering my questions! I'm not much of a systems dev so this is somewhat new territory for me
An extra note on this: currently if you want something generic that is not tied to the platform, like State
would likely be, you have to use Box
around it. That way, the platform just sees it as a pointer and can pass it along without knowing anything about it.
This example is out of date with current roc, but would be relatively easy to update:
Main function signatures: https://github.com/bhansconnect/roc-ecs/blob/trunk/roc-simple-ecs/Package-Config.roc
The platform wrapper and how it interacts with Roc: https://github.com/bhansconnect/roc-ecs/blob/trunk/roc-simple-ecs/roc-ecs-platform.h
As a first foray into Roc, this probably would be a bit complicated to get set up, especially if you are not used to lower level languages.
well yes but we're here to help. What language are you using for the host?
I'm using rust, and have been dabbling in it for years*
Thanks for the example, that was the next problem I was going to tackle, as you're right I would like the State to be opaque to the platform
then stack allocation becomes a bit harder, because the platform needs a place to put the value
and you don't know statically how large it will be
So if it's boxed, it would be allocated on the heap instead? Similar to rust?
Yes
On the heap with a refcount.
yes, or you just sort of guess the maximum size and store into an array of bytes
on the stack
Well I will give it a shot, I can always refactor if perf becomes an issue. @Brendan Hansknecht I'm assuming that's your ecs repo? How did your experiment go?
however that might still run into problems with the ABI
Yeah, it is my repo, feel free to reach out with questions in general. I can also update it to current Roc if you want (I think it is only minor changes).
The current difference between this and the equivalent code written in c++ is about 5x. So definitely a hit currently. That being said, it is still running so fast my terrible drawing pipeline is the bottleneck. Some details about it in #beginners > ECS. I think Roc should be able to close that gap, but box currently is totatly unoptimized and probably leads to a lot more copying than it should.
Would need to look into it again to figure out the performance costs.
No need to update it for my sake, I'll do some digging into it when I have the chance. For the time being I might just leave the state in the platform until that starts causing me problems. As far as performance, I don't anticipate it mattering as much for an ascii roguelike but the best method is probably just to try it out and see, thanks!
Oh, also, I just realized that there is a likely better example in the Roc repo. It is up to date and built with rust: https://github.com/rtfeldman/roc/tree/trunk/examples/breakout
https://mobile.twitter.com/roc_lang/status/1554586049417977857 is a demo of both of those platforms!
Here's a demo from @phillyete 2022 of early-stage native desktop apps in Roc, with a bonus demo of cross-compiling Roc applications to self-contained executables that run on other operating systems: https://youtu.be/XnbKVTO0eUE
- Roc (@roc_lang)Last updated: Jul 06 2025 at 12:14 UTC