Sam Hughes (Dec 11 2021 at 21:57): Sam Hughes (Dec 11 2021 at 21:57):I think it’d be useful to have some planning around the desired API to be offered by the initial three platforms, so that individual contributors can contribute pieces that each work towards a well-engineered, consistent interface.
I’d like if this could end up as a sort of “contributors’ menu”, where folks like me can check in, claim something, and then PR back in without the burden of engineering and syncretizing sections of the API to contribute.
Brendan Hansknecht (Dec 12 2021 at 02:46):What do you mean when you say "initial three platforms"?
Lucas Rosa (Dec 12 2021 at 03:04):yea I’m also not sure what that means. And I’m not sure there’s ever going to be a notion of a desired API. The API is generally completely up to the platform author
Lucas Rosa (Dec 12 2021 at 03:05):It’s important to note that roc platforms aren’t things like linux, windows, and macOS etc. They are just a host for roc application code and they can be as general or as specific to a domain as they want to be
Lucas Rosa (Dec 12 2021 at 03:07):One could make a roc Platform that mirrors the go standard library or one specifically just for web servers or even more specifically just for REST based JSON APIs
Lucas Rosa (Dec 12 2021 at 03:11):That said there’s been light talk around something called capability modules which offers a baseline of functions and type signatures kinda like interfaces that platform authors could opt into, which could prevent fragmentation around something like say HTTP stuff. But those wouldn’t have any implementation details baked in and platform authors would have the option to just ignore it completely and role their own.
Brian Carroll (Dec 12 2021 at 10:48):During the "Roc casual hangout" yesterday (which was happening around the time Sam posted this topic) I asked what would be the top 3 most important platforms for us to develop. Maybe Sam got the impression that this was an established idea, rather than a question I just came up with in the moment!
I do think it would be good to pick a few specific platforms to develop API ideas for. It's cool that a platform "could be anything" but that can also make things a bit unfocused!
However I think we're not ready for upfront API planning and checklists of features to tick off. That would need a lot more certainty than we have right now. We're in more of an "exploration" phase. We don't know exactly what the scope of a platform is, etc. More likely we'll come up with an idea for a platform API, build parts of it, run into problems, rethink it, try something different, etc.
But maybe we could start figuring out what we want the APIs to look like for specific platforms like CLI, web server, native GUI...
Brian Carroll (Dec 12 2021 at 10:55):Actually I'm not 100% sure what the current status is. As far as I know, there are lots of "hello world" and "test" platforms but not really any "real" ones. And a few people working on specific use cases. And I think Richard working on API designs for a CLI platform.
jan kili (Dec 12 2021 at 10:59):I think @Sam Hughes is referring to the first three "example" platforms provided in the official repo, but I don't know what those are beyond the CLI platform. I personally would like to see the CLI platform (and maybe one or two other broadly-useful primitive-ish example platforms) graduate from an "example" platform to an "official" platform. Once I'm using Roc in production (which I'm looking forward to doing someday :grinning:), it would be weird to either import from examples/ or need to shop around the community platforms market just to build a simple CLI. However, I would also understand if the Roc team don't want to maintain any production-grade platforms.
jan kili (Dec 12 2021 at 11:03):In that context of "official" platform(s), I agree that defining the API before implementing the handlers would help contributors claim+implement tasks. I'm imagining something like https://github.com/rtfeldman/roc/issues/664 but for platform tasks/functions.
jan kili (Dec 12 2021 at 11:05):Whoops, didn't see @Brian Carroll 's post until now - what he said!
Richard Feldman (Dec 12 2021 at 13:19):I would also understand if the Roc team don't want to maintain any production-grade platforms.
yeah so I want to avoid giving any platforms special treatment other than reputation - that is, maybe there's a platform that happens to be made by some of the same people who make the language, which would have some obvious implications for its reputation, but I'd like to avoid saying "this is the Official CLI Platform"
Richard Feldman (Dec 12 2021 at 13:21):the reason for that is more that I'd like to encourage innovation - give people a sense that if they want to experiment with a broadly-scoped CLI platform that they think will be better than the most popular one, they can do that, and although it's unavoidably going to be harder for them to get noticed (reputation is always going to be a major factor there no matter what), there isn't a formal ceiling of official-ness that they can never break through no matter how great their design is
Richard Feldman (Dec 12 2021 at 13:23):the other part is that there are an infinite number of potential platforms that can be made, and I wouldn't want to say "these use cases are Officially Supported and these others aren't"
Richard Feldman (Dec 12 2021 at 13:24):like if someone makes an Arduino platform, I wouldn't want it to seem like a second-class citizen among platforms just because nobody who works on the language knows enough about Arduino to make an official Arduino platform :big_smile:
jan kili (Dec 12 2021 at 13:28):That's all fair. One thing I like about Roc is that you have multiple unique theories for how to push DX (developer experience) forward, and you're enforcing the practical consequences of those theories!
Brendan Hansknecht (Dec 12 2021 at 17:59):I feel like the real goal here is to make production grade examples to help people learn what good platform design is and what a less trivial example app looks like.
Brendan Hansknecht (Dec 12 2021 at 18:13):Also, related question, do we have boxing yet? I think that will be really important for good platform design. For example, with a model view update style platform, the model should be boxed and sent to the platform because the platform doesn't care about what it contains. Without boxing, the platform needs to be designed explicitly for the model of the app.
Lucas Rosa (Dec 12 2021 at 18:23):Oh ok I understand now
Lucas Rosa (Dec 12 2021 at 18:26):I don't think things are ready enough to start entertaining production grade platforms anyways, there's a few more bugs to sort out. Maybe in another few months to a year, there's also the matter of the editor which will take more time as well
Lucas Rosa (Dec 12 2021 at 18:27):It's hard to give a timeline for this kind of thing, but I'd say we are still pre-alpha. But I'm happy to be wrong
Brendan Hansknecht (Dec 12 2021 at 18:33):I think it is still early stages, but definitely getting close to the point where we could design nice platform apis for something like a cli app or a gui app.
Brendan Hansknecht (Dec 12 2021 at 18:33):Not that roc would actually be production ready, but that the platform api and designs could be more ergonomic and idiomatic
Zeljko Nesic (Dec 14 2021 at 14:57):Also bare in mind to different timeframes:
being beta public ready ( having some editor to show off) vs.
being production ready which would imply it's reliable and feature rich enough that people have implemented and shipped an Roc Application.
Both will be very exciting dates :)
Last updated: Jun 16 2026 at 16:19 UTC