Nikita Mounier (Apr 08 2022 at 11:58): Nikita Mounier (Apr 08 2022 at 11:58):I've been thinking about the Roc package ecosystem, and how Roc packages interact with platforms. Say I'm building a 2D game in Roc, and my platform is a game engine. However, I realise I need to make API calls to my online service to update account details, so I install a low-level high-performance async HTTP client package whose platform is written in Zig.
What platform does my app build on top of then? The game engine or the zig platform? What would it mean for there to be a different memory allocator defined on each platform, both working at the same time, one for when I'm rendering graphics and one for when I'm making HTTP calls?
I haven't read anything about this so I'm wondering what the design philosophy would be for this.
Richard Feldman (Apr 08 2022 at 14:11):so every application has to have exactly 1 platform - no more, no less
Richard Feldman (Apr 08 2022 at 14:11):which means if you're building a 2D game in Roc, and your platform is a game engine, that's your 1 platform! :big_smile:
Richard Feldman (Apr 08 2022 at 14:12):so this wouldn't be a thing:
so I install a low-level high-performance async HTTP client package whose platform is written in Zig
Richard Feldman (Apr 08 2022 at 14:12):the game engine would provide HTTP primitives (if it decides to)
jan kili (Apr 08 2022 at 15:59):Or you'd switch to a platform that has everything you need... or fork the platform to add the additional features you need.
jan kili (Apr 08 2022 at 16:01):While the goal is an ecosystem of well-scoped platforms, I'm concerned that incentives might lead to popular platforms getting bloated. However, I'm curious to see what code reuse patterns emerge - perhaps a platform plugin system will make sense.
Brendan Hansknecht (Apr 08 2022 at 16:05):Yeah, it will be interesting to see how this pans out. Definitely should think more about platform composability
Brendan Hansknecht (Apr 08 2022 at 16:23):Currently the answer is that their is none. I mean it can be done in the platform ecosystem but not the roc ecosystem. Someone could make a rust http wrapper for roc and share that with many platforms, but that wouldn't be managed by anything related to roc.
Nikita Mounier (Apr 08 2022 at 18:52):Right, it's gonna be interesting. Is the aim to have a couple big standard platforms, one for each use case? Say one standard cli platform, one wasm-dev platform, one game engine platform, and one GUI platform? Or is it expected that each company/entity could create their own platform suited to their needs (maybe one wants their server to use ARC while the other only wants their server to use arena allocation)? Because yeah, it could be difficult to have varied platform use and a thriving package ecosystem if it means reimplementing everything just because you want, say, a different memory allocator, or use different graphics primitives. Idk, maybe it's' too early to think about this --- what do you think?
Nikita Mounier (Apr 08 2022 at 18:54):I think we could come up with some very cool platform composability tools to help with this though
Kesanov (Apr 08 2022 at 19:04):Richard Feldman said:
so every application has to have exactly 1 platform - no more, no less
Wouldn't it be in theory possible to switch platforms for things like crosscompilation?
Richard Feldman (Apr 08 2022 at 20:21):so one of the things I've found really great about Elm is that it focuses on one domain (UIs in the browser) and then builds a really cohesive experience around that, where all the APIs and primitives fit together really nicely
Richard Feldman (Apr 08 2022 at 20:21):a big part of that is that they're all designed together
Richard Feldman (Apr 08 2022 at 20:21):the original motivation for the platforms and applications design was to answer the question "how can we let people create that same kind of experience, except for the long tail of domains?"
Richard Feldman (Apr 08 2022 at 20:21):so to me, "composing platforms" sounds like a step in the wrong direction :big_smile:
Richard Feldman (Apr 08 2022 at 20:22):now code sharing between platforms sounds :100:
Richard Feldman (Apr 08 2022 at 20:24):but I think you have to pick one - either:
you can't have both, and I think we should try the first one because most languages effectively do the other one :smiley:
Richard Feldman (Apr 08 2022 at 20:29):also I predict that if Roc becomes popular, there will be both a small number of big platforms that get used by a lot of application authors, and also a long tail of platforms with a much smaller number of applications built on them
Zeljko Nesic (Apr 09 2022 at 10:25):Eventually patterns will emerge, and we may abstract some stuff out, but aiming for composability is hard and unclear task right now.
Kevin Gillette (Apr 09 2022 at 14:32):I agree that "here are all my composed platforms" sounds a bit painful, but i also agree that it'd be good to see patterns emerge. If you want to build CLI tools and web servers in the same project (service with support tooling), and both need to do HTTP client requests, but the community recommended really robust CLI platform exposes HTTP requests in a way that feels like wget, while the web server platform exposes curl-style requests, code sharing and interoperation will feel painful.
If that's the case, Roc developers will end up abstracting or adapting the platform for anything not platform-unique, just as a matter of course (essentially a form of boilerplate, in this case to hide http handling inconsistencies across platforms the project uses), instead of directing all effort towards application building.
This will particularly be the case for platforms whose authors don't really know or care about a given capability, for example, a game engine platform might have pretty poor or non-existent file io and networking capabilities except for the one state save format they support and the one network protocol they invented. This can be liberating for new projects on the platform (no choice means no time spent choosing), but rules out or significantly limits porting an existing game to the platform.
I'm not convinced that the Elm single-platform cohesiveness point applies well to the long tail of Roc platforms. The core Elm platform covers most of what people writing a web frontend need to do, but that's pretty limited compared to what we can do with native applications on modern operating systems: browser JS cannot generally send or receive arbitrary network data, or perform direct file io (including atomic writes vs streaming appends), or invoke other programs.
Elm doesn't need to solve these because the constraints of its environment mean that it literally can't. In contrast, I suspect there will be some applications on any conceivable non-browser/non-embedded platform that quite legitimately need the above capabilities.
In a way, the web platform is the most constrained and therefore simplest model of a platform; microcontrollers with 16K memory and 8 io ports would be another example of a very constrained environment which Roc could target. But I'd suggest that web (or embedded) is not a particularly great reference model for Roc, and CLI is the better "touchstone" for Roc to focus on getting right. CLI applications, as a domain, have more breadth than other platform types by far. These include network scanning, network load testing, fs/disk partition management (fsck/fdisk), directory/file-content search (find/grep), file copy (rsync), archival (tar). Many are interactive (top, ncdu, rogue). Many do signal handling. Modern systems often need to do all of these things (kubernetes). I don't see why a sufficiently powerful platform wouldn't let us do these all, perhaps more safely, in a functional language.
I'm confident we'll get to a pretty good place, and to find that, we'll likely have a period of chaotic platform experimentation in which interoperability of the same task (e.g. http) across platforms is quite lacking, but that'll afford us the opportunity to find optimal representations for common tasks. I believe it'll be an inevitability, if Roc is to have solid adoption growth, for common needs to get core task/record representations (stdlib http request/response records), or at least a clear 3rd party Roc module for those definitions.
I've found that good common implementations are powerful, even if complex (can express all of a concept in networking, or all modern aspects of disk io), relying on other modules to wrap and simplify (for example, the core representation of http tasks embraces streaming, and so can handle unbounded requests/responses, even though many will use a simpler wrapper/abstraction around that which buffers the response body into a string). Implementations that focus too much on simplicity at the expense of power may regret the choice: consider Python 2's stdlib http module, which nobody uses, then urllib and urllib2, finally ending up with urllib3 (each in the sequence either took too simple/limited an approach, or in the case of the http module, was flexible only in that it forced the caller to do most of the low-level work).
jan kili (Apr 10 2022 at 17:04):I agree with everything everyone said above, except maybe @Kevin Gillette's assertion that CLI applications are a "domain". I don't know exactly what a "domain" is, but in this discussion it seems like a space of apps for which the app authors have similar goals and needs. If "CLIs" is a "domain" in that sense, then they're likely the broadest software domain on Earth, and they will either need an uberplatform (that supports everything possible) or many scoped platforms. If "CLIs" isn't a "domain", then is it a catch-all "null domain" for arbitrary executables? Is it a tempting grouping for adjacent small domains? On second thought, I don't know if this philosophizing is useful :sweat_smile:
jan kili (Apr 10 2022 at 17:11):(I'm also one of the people who requested/semi-started a platform for "production CLIs", so I recognize the hypocrisy / existential crisis there, haha)
jan kili (Apr 10 2022 at 17:13):Also, I like the idea of "long tail of domains", but I don't see that as equivalent to "long tail of applications".
jan kili (Apr 10 2022 at 17:14):I don't think that Roc should be designed for porting arbitrary executables with arbitrary I/O.
Kevin Gillette (Apr 10 2022 at 17:25):JanCVanB said:
Also, I like the idea of "long tail of domains", but I don't see that as equivalent to "long tail of applications".
I'd love to hear more of your thoughts on this distinction
JanCVanB said:
I don't think that Roc should be designed for porting arbitrary executables with arbitrary I/O.
Do you mean "Roc isn't the best fit for every type of programming?"
I'd certainly agree with this. Short of many-paradigm languages (like Python, which at least so far is notably CPU-slow for many tasks in practice), even general purpose languages will tend to favor, or differentiate itself, for performing of tasks instead of others.
Let's pretend that, 5 years from now, we're at a point where we've already got a 1.0 stable language/compiler release. What is the "skills expectation" for an effective, average, Roc programmer? Do we invest in good-enough platforms that cover the majority of non-niche cases that Roc is reasonably well suited for, or do we expect productive, average Roc programmers to spend a regular portion of their time writing host code?
Brendan Hansknecht (Apr 10 2022 at 18:57):Do we invest in good-enough platforms that cover the majority of non-niche cases that Roc is reasonably well suited for, or do we expect productive, average Roc programmers to spend a regular portion of their time writing host code?
I think the definitely goal is that the average roc programmer just has to pick a platform, no need to mess with it or write their own. That being said, I would expect many companies to want their own platforms for more control and tailoring. Might even be common for people to fork and customize (hopefully a few) core platforms to build their specific versions.
Last updated: Jun 16 2026 at 16:19 UTC