Brian Hicks (Sep 21 2022 at 17:21): Brian Hicks (Sep 21 2022 at 17:21):I was talking with my team at work about Roc today. Someone pointed out that having custom platforms is a good way to not have to wait for (e.g.) database drivers to get wrapped and packaged. It made me think! How do we actually plan to manage that? If there’s some binary protocol (let’s say Postgres for example) which there’s a stable C or Rust or whatever library, will we maybe have two platforms? Or will it be up to the platform to design for their own extensibility?
Richard Feldman (Sep 21 2022 at 17:22):platforms are like the Highlander: there can be only one! :big_smile:
Richard Feldman (Sep 21 2022 at 17:26):to me, the incentive structure here is good - it means that:
Brendan Hansknecht (Sep 21 2022 at 18:13):I think it is also important to include an alternative to number 2.
Instead of the protocol being implemented in Roc, a good generic Roc api could be generated for relational DB queries. That api then would be implemented by many platforms making it easier to jump from the rust-webserver-postgres to rust-websever-mysql platform. It could even be a no-op in the Roc code potentially.
Brian Hicks (Sep 21 2022 at 18:39):or I could eventually lower the datalog I know I'll end up writing using tags as free variables :smiling_devil:
Zeljko Nesic (Sep 21 2022 at 23:57):Ok, it can be only one, but can it be extended?
Eg, is in principle create a system of extending a platform, so something like extendPlatfom: OnlyOnePlatform -> OnlyOnePlatform maybe written in host language, so we can plug-in random nice stuff for free?
Zeljko Nesic (Sep 22 2022 at 00:00):Eg, CLI platform gets extended with roc-database-rust ~platform extender~ so you don't have to wait upstream changes to play with it?
Brendan Hansknecht (Sep 22 2022 at 00:41):If it is in the host language, i don't think there is really a reasonable way for roc to handle this.
Probably should just use tools of the host languages and standard software tools like forking in git. I'm not sure what we reasonably could do for something of that nature.
Brendan Hansknecht (Sep 22 2022 at 00:42):Would be cool, but would require roc understanding and modifying hosts no matter the language they happen to be written in.
Georges Boris (Sep 22 2022 at 02:08):I was thinking about that in a Roc hangout call a while ago... maybe there will be multiple pieces that will be commonly composed on platforms... db-connectors, ui-renderers, http-clients, etc.
Perhaps a platform specific abstraction will pop-up for that but I think it can live outside of Roc itself? I wonder how would libraries that work on top of that work.
Say I have an abstraction layer on top of postgres-connector that I wanna publish - would I be able to publish a package that depends on a specific platform-exposed module? Or would we need a more complex graph of dependencies between packages and platforms for composability? (e.g. platforms would depend on an abstract API package that would then be extended by other people - each platform reimplementing its effect handlers)
Brendan Hansknecht (Sep 22 2022 at 03:56):Yeah, it gets complex. Definitely have to think about apis a lot more when it comes to platform boundaries.
One option is platforms to expose the same interface. Another is for the library to define the expected types and the platform or app to define converters. Yet another option is just to tie to a specific platform and limit library scope.
I think the correct answer will heavily depend on context, but it would definitely be good to test potential solutions earlier.
Brendan Hansknecht (Sep 22 2022 at 03:58):As an example if we have two libraries that both expose drawing primitives, it should be possible to build a generic drawing library with adaptors that can convert to either platform. That being said, if the primitives are too far away from what the library expects the conversion may be painful and very slow. So there are definitely limits around compatibility.
Last updated: Jul 26 2025 at 12:14 UTC