Stream: beginners

Topic: platform dependent libraries


view this post on Zulip Leander Behr (Dec 31 2022 at 12:19):

How are libraries going to work that depend on things provided by platforms? Say a library for file IO. You wouldn't want to reimplement it for every platform but there's also no standard interface you can rely on. Afaiu you actually have to import a platform into the lib to use IO primitives right?

Closely related to this, how do platforms compose? In a decently sized application you'll want many things like e.g. file IO, graphics, maybe an entity component system and more for a game. Does this always have to be provided as a monolith with the composition happening on the rust/zig/c side?

view this post on Zulip Brendan Hansknecht (Dec 31 2022 at 12:28):

Platforms do not compose.

view this post on Zulip Brendan Hansknecht (Dec 31 2022 at 12:28):

They require libraries in the host language to compose

view this post on Zulip Leander Behr (Dec 31 2022 at 12:28):

Does the interface feature allow to require things? That could be a way to write libs against an api and have the application provide the required api based on its platform

view this post on Zulip Brendan Hansknecht (Dec 31 2022 at 12:32):

As for a library that depends on a platform. It depends. Generally speaking there are two main options:

  1. Share types - currently no native way to make sure this is in sync and maybe not always possible due to opaque types. That may or may not change in the future.
  2. Have mapper functions to go from library types to platform types and effects. Hopefully this will become standardize as better formats are discovered. Then the drawing library can define graphic primitives that map to multiple graphics platforms.

view this post on Zulip Brendan Hansknecht (Dec 31 2022 at 12:33):

Honestly neither of these is necessarily optimal. I expect some sort of change as this becomes more common

view this post on Zulip Brendan Hansknecht (Dec 31 2022 at 12:34):

I guess there is a third option: bundle the library with the platform.

view this post on Zulip Richard Feldman (Dec 31 2022 at 13:56):

there are potentially more options in this space with the interpreted effects design, but that's still WIP

view this post on Zulip Richard Feldman (Dec 31 2022 at 14:26):

I'll write up a design doc for it at some point, but ideas are still percolating plus we don't have a proof of concept platform using it yet - although I'm planning to get back to that next week now that Advent of Code is over!

view this post on Zulip Luke Boswell (Dec 31 2022 at 15:33):

I'm keen to explore this design space using roc-tui if that would help; I would love to share code for effects with cli if possible. I've wondered if it might be possible to have roc glue support interfaces/packages, with the idea to write a host language library which can be shared.

In a decently sized application you'll want many things like e.g. file IO, graphics, maybe an entity component system and more for a game

From previous discussion, I understand the intent is for platforms to naturally evolve around use-cases; and not necessarily general purpose. For example there might be a number of popular game dev platforms evolve which would provide effects and functionality specific to games. These platforms might optimise for a game loop etc.

Related to this concept is that when you have a more niche use-case then you are encouraged to fork one of these platforms and add the functionality you need. It may be something that many people also need, and then be something that could feedback into the evolution of the platform. Note that with roc glue it should be easy to change the API if needed and re-generate any glue code.

view this post on Zulip Richard Feldman (Dec 31 2022 at 18:14):

yeah I think the next step regardless is to get effect interpreters working. From there I think we have sufficient primitives to try out some interesting ideas, but they're all predicated on that design actually working in practice, which hasn't been demonstrated yet :big_smile:

view this post on Zulip Kiryl Dziamura (Jun 25 2024 at 18:20):

any updates here? it feels like a realistic need, but was it asked for to that moment?
right now, platforms are small, but I imagine it's possible a platform provides bare minimum api, and there are multiple platform-dependent roc modules that implement different frontends.

upd: looks like it's exactly what module params for!


Last updated: Jul 06 2025 at 12:14 UTC