itmuckel (Mar 18 2023 at 09:54): itmuckel (Mar 18 2023 at 09:54):I have a general question regarding platforms. As far as I understand a platform executes roc code to trigger side effects or so. But what if for example I want to write a music making software which needs GUI and audio libraries? Would I need to write a new platform or fork the gui platform and add roc-wrappers for calls to an audio library? In general gui applications do not provide gui and that's it, they do all sorts of stuff, like spotify for example (calling a server, downloading music, playing music...). I imagine having to write for example a library in rust and use roc as a glue language for the library. Like how game engines are usually written in C++ and use a scripting language like lua for game logic. Is this how roc is supposed to work?
itmuckel (Mar 18 2023 at 10:02):I can also think of server applications that need to talk to mysql/postgres or redis, need to provide a rest api or a graphql api or so. Are platforms flexible enough? Will there be the need for a very big server platform covering all potential needs of a roc application?
Brendan Hansknecht (Mar 18 2023 at 14:49):Fundamentally, 2 unique platforms can not be combined. Each of them is code that would compile to a standalone executable. That said, code reuse between platforms and more flexible platforms are still possible. Platforms have full access to the host languages package ecosystem. Libraries tailored to Roc could be added to these package ecosystems enabling a platform to easily add sound for example. On top of that, the platform could enable conditional compilation such that a Roc user can pick the variant of it with the specific pieces they need.
Brendan Hansknecht (Mar 18 2023 at 14:52):Would I need to write a new platform or fork the gui platform and add roc-wrappers for calls to an audio library?
Very possibly you would need to do exactly this. I think it mostly depends on how complex of an application you want to build and what special features it has. If no platform fits your needs, you would need to modify one or make your own. That said, I would assume, for people who never want touch a platform, there will be some rather flexible platforms that arise. They may be quite large, but they also would give the largest swath of potential features.
Brendan Hansknecht (Mar 18 2023 at 14:53):use a scripting language like lua for game logic. Is this how roc is supposed to work?
That is definitely one explicitly use case of Roc, but I think it expands past that. Some areas, I think platform will be designed well enough that you wouldn't touch or really think about the underlying platform.
Brendan Hansknecht (Mar 18 2023 at 14:55):need to talk to mysql/postgres or redis, need to provide a rest api or a graphql api or so. Are platforms flexible enough?
For all of these, the platform just needs to provide Roc a way to talk over the network. Packages written in Roc could deal with each of the specific protocols. They, unsurprisingly, don't exist yet, but there is nothing stopping them from being built. So the flexibility could definitely come from the Roc package ecosystem rather than the platform apis.
Brendan Hansknecht (Mar 18 2023 at 14:59):Will there be the need for a very big server platform covering all potential needs of a roc application?
Need? nope, but I think especially medium term, having giant platforms that kinda just do a ton will be common. Right now, most platforms are custom to one or a few apps. As time progress, I think some areas will get platforms that are good enough for 95% of use cases in the area. These platform will likely be really large and do everything in the platform. In the very long term, I would expect many of these to slim as flexability is built into them and more pieces are moved into the roc package ecosystem.
Brendan Hansknecht (Mar 18 2023 at 14:59):But that is all just speculative.
dank (Mar 18 2023 at 15:35):Brendan Hansknecht said:
Fundamentally, 2 unique platforms can not be combined. Each of them is code that would compile to a standalone executable. That said, code reuse between platforms and more flexible platforms are still possible. Platforms have full access to the host languages package ecosystem. Libraries tailored to Roc could be added to these package ecosystems enabling a platform to easily add sound for example. On top of that, the platform could enable conditional compilation such that a Roc user can pick the variant of it with the specific pieces they need.
why not actually (theoretically)?
lib-like platforms
compile each to an object file that would just link against the app
Brendan Hansknecht (Mar 18 2023 at 15:43):An executable in C, a lib in C, and a Roc app would be 1 roc platform made out of an executable and lib in C and a Roc app.
Brendan Hansknecht (Mar 18 2023 at 15:43):If the executable never calls into or uses the lib in C, it is just dead code.
Brendan Hansknecht (Mar 18 2023 at 15:44):Fundamentally there is only 1 main. It drives everything.
dank (Mar 18 2023 at 15:47):Brendan Hansknecht said:
If the executable never calls into or uses the lib in C, it is just dead code.
i mean could theoretically eliminate it at compile time (if you could also compile all three together)
dank (Mar 18 2023 at 15:48):Brendan Hansknecht said:
Fundamentally there is only 1 main. It drives everything.
yea
by that main you could compile the rest
dank (Mar 18 2023 at 15:49):it doesn't sound impossible
just may go against roc design (which idk if it does tbh)
Brendan Hansknecht (Mar 18 2023 at 15:57):About main, what I mean is this:
If I add in another C library, that is a "library platform". What is it gonna do? When is the main C platform of the actual executable gonna call into it? The main C platform does not know about it and will not call into it, So, it will always be dead code.
The way to do something like this with Roc would be to modify the main C platform to make it use the C library. This is really just expanding the main C platform. There is no merging of two platforms from Roc's point of view. It would not happen automatically (well, maybe with an ifdef), but fundamentally would be forking the platform and making a larger platform with more capabilities.
itmuckel (Mar 18 2023 at 16:06):Ah, interesting, so as long as the provided platform is "powerful" enough, libraries can be written completely in roc. Should also work performance wise :thinking:
Brendan Hansknecht (Mar 18 2023 at 16:11):I think it will work performance wise. Given some roc tag union representing the request, convert it to a list of bytes with some metadata to pass to the platform.
Brendan Hansknecht (Mar 18 2023 at 16:12):But only time will tell where this exact trade off lands.
Last updated: Jul 06 2025 at 12:14 UTC