As far as I understood about platforms, it is a low-level binding to the running environment, that is written in languages with APIs for platform specific stuff.
Let's assume I want to create a platform for concurrency, the requirement is that I need to be able to allocate memory. Should this assume that I can access/depend on another platform for this specific task, or it will be implemented with memory allocation directly from platform.
There was some discussion on a related question fairly recently, I believe that everything in that thread is still accurate.
I think a key thing @Brendan Hansknecht said in that thread is that Roc specific packages could be written for different host languages, e.g. if you wanted great concurrency there could be an Elixir package that implemented the memory management for Roc, then writing a new platform using Elixir would be as simple as importing that library and adding some customisations
Oh, and to answer your question more directly, an app can only depend on exactly one platform, so your platform couldn't depend on another platform.
I think the idea of a "platform for concurrency" doesn't really fit with Roc's concept of platforms. It's not the right level of abstraction to think about. I would expect Roc to have a platform for command line applications, a platform for web servers, a platform for video games, etc. And some of those platforms would implement concurrency as a feature.
Currently the most developed platform is basic-cli
This doesn't seem to be any fun, ultimately you will have to rely on concurrency model provided by the language of the platform and all the problems it brings with it. I've asked before about the concurrency in roc and the answer was pointing to implementing it in a platform #beginners > What is the concurrency model .
Yes that's right, it's implemented in the platform. But that doesn't mean that it's the only thing the platform does.
It seems I am missing a key factor about how platforms operate. From reading the thread above, platforms are executables running in their own environment and have a communication channel to interact with roc, if that is the case, then a platform cannot add the functionality of concurrency to the roc runtime itself, roc can only delegate such things to the platform.
Now if that is the case, then would it be possible to send asynchronous events between runtimes?
Now that I think about it, it doesn't seem to make much sense, as you cannot pass code to be executed to other platform, so this means roc cannot have a concurrency system in application layer that is not baked into the language.
Roc and the platform are separately compiled to object files, and those two object files are linked into a single executable. So there is not really a communication channel, just direct function calls.
Okay it seems a little bit more clear, the comment about elixir package misled me, as elixir runs in a VM and it is not possible to bake it in the same runtime as roc.
Thanks for the help!
Roc totally could be used with an elixir based actor platform. The platform would be more than just concurrency, but the base of the platform could be written in an elixir library and shared. That is the closest we get to composable platforms (code sharing in the host language)
Roughly how it could work:
Thank you @Brendan Hansknecht, I used Elixir as an example but don't know enough about it to explain the details :sweat_smile:
Last updated: Jul 06 2025 at 12:14 UTC