Stream: ideas

Topic: pure apps

Anton (Jul 31 2026 at 18:05):

It would be nice if we made it easy to publish, share and use pure apps. Like there are a ton of apps that take one or more files from a specified directory, process them and output one or more files. I could have this locked down, up-to-date, trustworthy platform that I like and it would be awesome if I could use it with all pure roc apps that take a list of files as input and a list of files as output.

It also removes a lot of burden from the app developer. They do not need to test on every OS roc supports and they don't need to update and publish anything in case the platform has a vulnerability.

Jasper Woudenberg (Jul 31 2026 at 18:50):

I'd have so many uses for this at my day jobs! Many instances where I write a quick script that does some data transformation on some .csv files, where I'd love to be able to quickly wrap that in something I can easily share with colleagues that don't program so they can run it as well.

Richard Feldman (Jul 31 2026 at 18:59):

that's a cool idea - roc glue already does the output side of this :thinking:

Karl (Jul 31 2026 at 19:03):

Is the restriction a subdirectory configurable at invocation? Something like platform --allow-dir ~/dev/roc-test <some_internet_script> or platform --allow-network https://roc-lang.org/docs

Richard Feldman (Jul 31 2026 at 19:08):

I assume the idea would be that you pass in explicit paths and/or globs as argmuents, and then the function just receives the contents of those files as a Dict(Path, List(U8)) or something like that

Karl (Jul 31 2026 at 19:16):

I think it'd be neat if you could do things locally and then just switch the config and do either end an s3 api bucket instead

Bryce Miller (Jul 31 2026 at 19:32):

If the app just provides a function to the platform that takes a list of files and returns a list of files, multiple platforms could use the same api. One platform for S3/b2, one for local files, etc. right?

Bryce Miller (Jul 31 2026 at 19:37):

Or one that can do any of the above, I suppose

Luke Boswell (Jul 31 2026 at 20:45):

This is similar to what basic-ssg does... and I have been thinking of changing the API a little further in this direction so it does even less ssg specific things and leaves that to Roc.

Norbert Hajagos (Jul 31 2026 at 20:51):

I can see the echo platform be extended to do stdin, stderr and stdout. That wouldn't be too much ask from the echo platform i think. With that, you can take a file's content and feed it into the program's stdin channel. Easy 1 to 1 mapping.
If you want to do more, you'd need to be more clever, which isn't as good of a thing, but you still could do everything.

for f in *.txt; do
  printf "\n--- FILENAME: %s ---\n" "$f"
  cat "$f"
done | ./your-pure-app

You'd parse the delimiters. Or if you're okay with relying on tar, you could accept a tar stream in you pure app, which packs the pathnames and content into a good format, not specified by arbitrary delimiters

# Package files to stdin
tar -cf - *.txt | ./your-pure-app

Same on the output side, just the other direction.
Though at that point you probably need a platform, which is fine in my mind. I wouldn't want to see this very specific set of constraints be picked by roc, because... Well they are very specific in my mind and a language shouldn't make decision about them i think.

Regardles, as a separate thing I think stderr and stdin would be welcome in the echo platform (which probably wouldn't be called echo platform at that point)

Richard Feldman (Jul 31 2026 at 21:11):

I need to write this up, but I've come around to the idea that the default platform from just echo! to supporting "safe scripting" use cases is a reasonable idea.

the specific thing I noticed is that for me personally I want scripts that can run in a sandbox with no network access. It's possible to do that with a platform if I make sure the platform's contents are already in the sandbox ahead of time, but it's an ergonomics gap compared to most scripting languages where all you need is the script and the interpreter.

or to say it another way, it's always been a goal for Roc to compete with Python and Lua and Deno on scripting, and I'm coming around to the idea that having a "sandboxed scripting" platform that's included in the roc CLI with no download might realistically be table stakes after all.

Richard Feldman (Jul 31 2026 at 21:12):

basically letting you do something like pf: platform _ or something like that

Richard Feldman (Jul 31 2026 at 21:14):

that does open a can of worms regarding what the API looks like, how to configure sandbox permissions, etc. but...all the scripting languages I want to compete with opened those cans of worms and came out the other side.

Richard Feldman (Jul 31 2026 at 21:15):

I'm sure we can too, and then all of the above use cases in this thread can Just Work, with no impact to the non-scripting "platform from URL" use cases

Jasper Woudenberg (Jul 31 2026 at 21:20):

Richard Feldman said:

the specific thing I noticed is that for me personally I want scripts that can run in a sandbox with no network access. It's possible to do that with a platform if I make sure the platform's contents are already in the sandbox ahead of time, but it's an ergonomics gap compared to most scripting languages where all you need is the script and the interpreter.

I get what you're saying and it makes sense, but it also makes me a bit sad because it means there would be one "blessed" CLI platform that at least in one regard will offer convenience that other platforms will never be able to match.

Richard Feldman (Jul 31 2026 at 21:22):

yeah that is the downside, which is why I resisted it for so long

Richard Feldman (Jul 31 2026 at 21:22):

the problem is it feels like the alternative is to be less useful for a use case that's always been a goal to be really good at

Richard Feldman (Jul 31 2026 at 21:23):

like if I personally find myself not reaching for Roc for scripting because of this, that's a pretty strong signal to me :laughing:

Jasper Woudenberg (Jul 31 2026 at 21:23):

Yeah, I get it

Karl (Jul 31 2026 at 21:47):

Richard Feldman said:

the specific thing I noticed is that for me personally I want scripts that can run in a sandbox with no network access. It's possible to do that with a platform if I make sure the platform's contents are already in the sandbox ahead of time, but it's an ergonomics gap compared to most scripting languages where all you need is the script and the interpreter.

I would like a solution for what I think of as "the network problem". Today I'm doing images on my UI platform and the decision comes up: support images coming from URLs or not. On one hand I'm trying to keep this whold thing familiar from a web dev background because I think most UI people are at least moderately familiar with that approach so I want images to just work but on the other hand I don't want an arbitrary http GET hole in every GUI I make. The semantics of fetch! are well established (requests, window.fetch) but the security boundary needs to be in the purview of someone closer to the final domain. In the context of the UI platform I don't really care how image bytes get in the buffer, I just want to read the dimensions, resample, and put it on the screen so I just allow a static image set at the moment. I've had a similar problem when deciding on a database for the web server so I pick sqlite because it's easy and good enough for a lot of things but obviously people are going to want postgres or something.

The other problem is "the shimming problem". Let's say this pure apps platform gets built and someone writes some cool algorithm that processes CSV files on their local machine and shares it on the platform. I want to take it and have it process my Arrow files on s3 . If the cool algorithm is written against Decoder and the pure apps platform has a CSV decoder module that takes a XFile then a module that produces a XFile from the corresponding OS specifics then I can write two pieces, compose them, and it magically works.

I don't know if these are technically feasible but it's a longstanding dream. I'm tracking the wasm component modules effort relatively closely because it's a closely related domain and I think it might work on its own and as a potential way to avoid the parochial code push I feel platforms naturally push me toward.

Jasper Woudenberg (Jul 31 2026 at 21:48):

This probably has tons of downsides I haven't considered, but another approach I wonder about is making it very easy for platforms to bundle Roc. So a programmer might enter the Roc ecosystem because they heard good things about a particular web server, scripting language, static site generator, whatever. They go to the website of that project (a platform), download it, and get that tool which also happens to bundle and install Roc behind the scenes. Still, from the point of view of an early Roc user they'd download and install a single thing.

Say one such platform is called rocy-script, it might use a shebang #!/usr/bin/env rocy-script that invokes Roc with a particular platform. When called this way providing an application header could be made optional.

Later the same programmer might learn their knowledge of Roc is portable, check out a platform for some other domain, realize they already have Roc installed and that they've everything they need installed, and try it out.

But I guess the key idea is to let platforms present themselves as a "single thing" to beginning users, and flip the conception of Roc as a programming language you combine with a platform, to a "scripting" language bundled with a couple of popular (hopefully!) programming frameworks.

To be clear: I'm not advocating all these platforms install their own Roc binaries in their own ways, technically things wouldn't be all that different (I think?).

Jasper Woudenberg (Jul 31 2026 at 22:06):

I don't think only CLI apps would benefit from this by the way. One of my hopes for Jay, the static site generator platform I'm working on, is that you can essentially develop in split screen mode: editor on one side, site preview on another. I want to try integrate Roc's compile and test errors into the browser preview, so that you don't need a third window open while developing, which I personally think would make a big impact (could be wrong though :smile: ). If I get it to work, developing with Jay would involve running ./build-site.roc and minimizing the terminal as it starts watch mode. You'd not need the roc cli command much.

I think that kind of approach could be interesting to other platforms that bundle a lot of their own development tooling. Mobile development certainly comes to mind.

Kasper Møller Andersen (Aug 01 2026 at 12:43):

So what's the difference between echo and basic-cli at this point? And looking at all other languages, their "platform" is essentially all some variation of full-cli; what's the value of having anything less than full-cli for Roc?

Let's say you make some script that only does file things, and now you need to also upload said file to S3. If you start with a platform that doesn't have networking, you now need to change platforms. If the platform you're moving to has an API that is strictly a superset of the API from the first platform, that may not be a big deal, but I don't understand the benefit of it. If users still have to wire up the effect execution in their code to the platform (this is how you execute HTTP GET, etc.), then isn't that where the user is opting in or out of such features anyway? So what's the benefit of having a platform that doesn't offer all the capabilities?

Kasper Møller Andersen (Aug 01 2026 at 12:48):

As someone who's spent a long time following Roc, I still don't quite understand what the idea is behind reaching for different platforms at different times. Do we want more than one cli platform for example? Maybe one per OS, and one that is cross-platform, but no more surely?

Richard Feldman (Aug 01 2026 at 12:54):

I think it's more obvious when UIs are involved

Richard Feldman (Aug 01 2026 at 12:56):

like imagine if you started with "echo plus I/O" and then you wanted to build an iOS app...that would be a really suboptimal foundation to have to build on :sweat_smile:

Richard Feldman (Aug 01 2026 at 12:57):

whereas a platform that gives you a single API for mobile apps, native desktop apps, etc. can do much better if it's able to specify the low-level platform for each of those

Richard Feldman (Aug 01 2026 at 12:59):

so then if you go backwards to the CLI case, I think a TUI platform makes a lot of sense, and it also makes sense to me that multiple TUI platforms would coexist because they have different APIs

Richard Feldman (Aug 01 2026 at 13:00):

same with multiple webserver platforms because they can all have different strategies and philosophies around memory management (e.g. arenas, memory limits per request, what happens if a request exceeds those limits, etc.) that should also coexist

Richard Feldman (Aug 01 2026 at 13:01):

is there a compelling reason to have a bunch of competing CLI (but not TUI) platforms? Maybe not. I wouldn't want to rule it out or anything, but we don't really see a big diversity of approaches to CLIs in other ecosystems the way we do TUIs and webservers and game engines and such

Richard Feldman (Aug 01 2026 at 13:01):

that said, SQLite is a pretty good reason in its own right

Richard Feldman (Aug 01 2026 at 13:02):

like putting SQLite into a default scripting platform sounds ridiculous, but it sounds totally reasonable for a separate cli platform

Richard Feldman (Aug 01 2026 at 13:03):

so "drop-in replacement for the default platform with SQLite baked in" sounds like a fine pitch to me!

(as an example of why someone might want to reach for a separate cli platform regardless)

Kasper Møller Andersen (Aug 01 2026 at 13:11):

For me, the problem with it is that it's the distinction between a library and a framework (you're calling the library, the framework is calling you), and composability. Frameworks generally don't compose, while libraries can be made to, at least. For example, let's say we have some full-cli platform and a full-cli + SQLite platform (like what you just described), as well as some tui platform. I build my app on full-cli + SQLite, and now I want a TUI on top. I would need someone to create a full-cli + SQLite + tui platform to be able to do so, rather than just adding a tui library to my application.

Richard Feldman (Aug 01 2026 at 13:23):

yeah "framework" was one of the names I was considering instead of "platform" - but frameworks don't manage memory for you or provide all your I/O primitives, so it's not quite accurate

Richard Feldman (Aug 01 2026 at 13:24):

SQLite is an outlier btw

Richard Feldman (Aug 01 2026 at 13:26):

we haven't found another dependency like it that requires I/O and is very performance sensitive and is traditionally a statically linked library

Richard Feldman (Aug 01 2026 at 13:27):

so it may turn out that most client platforms offer it alongside normal file I/O operations

Richard Feldman (Aug 01 2026 at 13:31):

also "I built my whole app and now I want a TUI on top" is not a situation I've ever heard of anyone being in :smile:

Richard Feldman (Aug 01 2026 at 13:32):

it's usually either "I built a TUI app" or "I converted my app to be a TUI" - and in both cases that seems like a change of "framework" to me

Kasper Møller Andersen (Aug 01 2026 at 13:36):

Another example would be web UI then. Presumably there would be multiple different platforms, where one platform is React-like, one is Elm-like, and so on, but they all still target the DOM. Now someone with a web app says "I want to run this in Electron". Presumably there would also be an electron platform, to open up the Electron API to the application. But if both my UI framework is a platform and Electron is a platform, I need to build a platform that combines the two, rather than compose them.

Richard Feldman (Aug 01 2026 at 13:38):

Kasper Møller Andersen said:

Now someone with a web app says "I want to run this in Electron". Presumably there would also be an electron platform, to open up the Electron API to the application. But if both my UI framework is a platform and Electron is a platform, I need to build a platform that combines the two, rather than compose them.

I don't think those use cases compose anywhere - not just a Roc thing

Richard Feldman (Aug 01 2026 at 13:39):

I haven't heard of "we had a web application and then we just composed in Electron and it Just Worked"

Richard Feldman (Aug 01 2026 at 13:40):

Electron has a totally different set of APIs from Web, and if you want to offer one set of APIs that works for both native desktop and web, that's a separate framework goal from targeting just one or the other

Richard Feldman (Aug 01 2026 at 13:41):

imo all the use cases you've mentioned so far (assuming SQLite is a standard thing client platforms offer) are really clear cut examples of where outside of Roc they don't compose, and would be handled by frameworks, and in Roc would be handled by platforms :smile:

Richard Feldman (Aug 01 2026 at 13:48):

which is where the split originally came from - the observation that in practice there are these big boundaries that have appeared naturally in different domains, and we could get benefits like domain-specific security guarantees (e.g. for plugins/extensions), domain-specific automatic memory management (e.g. arenas strategically in some places but not others), and domain-specific I/O primitives (e.g. no filesystem stuff in the browser, or maybe automatically using a game engine's logging system instead of stderr, etc.) by making that a first-class thing in the language

Arya Elfren (Aug 01 2026 at 14:19):

Richard Feldman said:

also "I built my whole app and now I want a TUI on top" is not a situation I've ever heard of anyone being in :smile:

There are a number of git TUIs that are just wrappers around the CLI. I also use isd a bunch wich is basically a TUI around the systemd CLIs. They don't convert or re-write the underlying CLIs, they just give some live feedback, fuzzy search, and keybinds/toggles for subcommands/flags.

I would actually be for bigger platforms and more abstracted apps: instead of sqlite specifically having an SQL-like API that the platform can decide is backed by memory, sqlite, a different database...

For example, you write a Roc app that takes some options, commands, and a set of files (or even structured data) and then returns a new set of files. I can then pick a platform (or more realistically for compatibility, the same platform with different feature flags) that takes the options from args or a config file, that opens the files/s3/stdin, and that then does the networking/io etc.

The roc app should not be the one to find config files and merge them with environment variables and arguments, if the platform is already doing that it should probably do the arg parsing to some degree. The roc app should not decide where the input comes from or the output goes (if not it would be a weaker sandbox) and so the difference between e.g. zip dirA dirB -o foo.zip and export CREDS="token"; cat bar | zip "https://sourceA" "ftp://sourceB" --include-stdin -o foo.zip should be in the platform and not the Roc App.

At least in a shell (which this default platform seems to target) you can already do all of these things if you just support reading files passed as arguments and writing to stdout: foo <(s3-get foo) localFile.txt | s3-push bar.

Kasper Møller Andersen (Aug 01 2026 at 14:47):

And I agree with the principle, but the cut between application, libraries, and platforms still doesn't feel like it's in the right place for me. Because I think we're trying to mix "expose the capabilities of the underlying platform" (i.e. the runtime environment) with "interact with the platform in this particular way" (i.e. the framework), and those feel like two distinct things that you don't always want to bundle up. Instead of a single platform abstraction, maybe there should be both a platform and an application_interface abstraction, to separate the two.

One of the big limitations of Roc today, in my mind, is that you can't really write this frameworkey code for your application in Roc, if it needs to live in the platform. But there's plenty of such code that could live in Roc just fine! For example, if I'm writing an Elm-like framework for UIs, and I need to diff virtual DOMs and what not, a lot of that code could presumably be written in Roc just fine, and I would get all the benefits that come with that.

Richard Feldman (Aug 01 2026 at 14:55):

sure, but platform authors can just write all that in Roc if they like! :smiley:

Richard Feldman (Aug 01 2026 at 14:56):

I think "too many layers" is a big problem in modern software, and I think software would work better if the bar for "introduce a new layer" were generally much higher than it is

Richard Feldman (Aug 01 2026 at 14:57):

I see part of the value of platforms as being an opportunity to collapse multiple layers into one, and I think it would be a step in the wrong direction to encourage people to build "frameworks" on top of platforms instead of e.g. forking a platform and taking its APIs in a different direction

Matthieu Pizenberg (Aug 01 2026 at 15:11):

It’s probably when 0.1 will hit that we will see anyway what people need, and what cross-platforms situations arise most often. And it’s not like roc can’t change between 0.1 to 0.2. IMO considering the time it took to get to 0.1, and the experimental aspect of platforms, better give it a shot, now, than regret not having tried it "for real" later.

Matthieu Pizenberg (Aug 01 2026 at 15:15):

If platforms are a concrete leverage to encourage people to write more Roc code, that’s also a good thing IMO. A bit like elm not having super easy JS interop encouraged people to rewrite in Elm replacements, with better APIs, for the original JS libraries.

Kasper Møller Andersen (Aug 01 2026 at 15:29):

Well, that answers my question. I agree having fewer layers in software in general would be nice, but I don't think collapsing underlying platform capabilities and framework code into the same thing is a healthy response to that. I think I would personally consider this pattern a liability that is less likely to make me choose Roc for a project if I were to choose a new technology for some development project, but I'm happy to be proven wrong about my concerns :slight_smile:

Jasper Woudenberg (Aug 01 2026 at 15:44):

Kasper Møller Andersen said in #ideas > pure apps:

Because I think we're trying to mix "expose the capabilities of the underlying platform" (i.e. the runtime environment) with "interact with the platform in this particular way" (i.e. the framework)

For me this is one of the things that gets me excited about platforms. I agree the platforms add constraints that aren't there in other general purpose programming languages. But this ability to add constraints can enable great development experiences. Like in Elm, which has all kind of constraints for the way you interact with the underlying runtime environment (the browser), then gets so many benefits out if in in terms of performance, debugability, and stability.

Normally the programming language sets the constraints, and then whatever the language allows all the code written in the language will have to cope with. Frameworks built on top of these languages can't "take back" what the language allows, and I think that in part explains why frameworks feel leaky and get (in some circles) a bad reputation.

I think having the possibilities to use constraints as a tool in designing a development experience, without needing to design a whole programming language plus ecosystem as well, could be huge. It massively lowers the cost for an expert in a particular programming domain to write down their knowledge of that domain in a format (the platform) that allows others to be successful in that domain.

Kasper Møller Andersen (Aug 01 2026 at 19:47):

To be clear, I completely agree with that goal. My disagreement is with the approach to getting there.I haven't thought this super well through, so I may be wrong, but the problems I think we'll have with the current approach go something like:

• Common operations will have inconsistent APIs across platforms, making it harder to carry knowledge across platforms (e.g. if every platform defines its own functions for reading files, then those functions will look different, return different errors, some platforms have streaming APIs, but not others, etc.)
• When people fork and come to own their platforms, they must assume responsibility for the whole thing, even if they just wanted to own the application framework. That also includes whatever I/O stack is included, and code that is critical for security.

This feels pretty bad to me, and if I am encouraged to maintain my own platform in Go or Rust alongside my Roc code, why wouldn't I just write my entire codebase in Go instead, and not deal with having multiple languages? Go is already mature and has solid APIs.

The question is: how valuable is it to have a nice and restrictive platform API compared to the free-for-all we have today? I would rate it as a nice-to-have, but not need-to-have. It definitely makes some things better, but it doesn't seem all that life changing. I _do_ think managing function purity the way Roc does is a huge deal, but whether that purity is baked all the way down into the platform or whether I have some framework on top of the platform which then defines what is pure or not, doesn't seem all that important to me.

What does the good solution then look like? I'm not sure, but I would consider things like:

• Separate all the I/O primitives from the framework. Maybe there would be a common library for file operations, and any platform that wants to offer file operations would provide effect handlers that map onto that library. Similar for stdin/out/err handling, networking, reading clocks, reading entropy for randomness, and so on. Platforms can still provide their own I/O operations that don't map onto such libraries as needed, but that should not be the common case.
• Allow people to restrict the application API without building a new platform. Imagine that platforms were mainly focused on just providing capabilities, and there then was a layer of Roc code sitting between the platform and the application. This middle layer is the framework, and would define the application interface, similar to what platforms do today. But now users can fork the framework without forking the platform. And if platforms mainly just expose capabilities, that makes them simpler and more stable.
• For platforms that want to offer more tailored capabilities (like memory arenas for web requests), I would want a way to build such functionality into a library that the Roc framework code can call and expose to the application as needed, without loading it through the platform directly. Thus making the platform independent of this capability.

Bryce Miller (Aug 01 2026 at 20:36):

Kasper Møller Andersen said:

The question is: how valuable is it to have a nice and restrictive platform API compared to the free-for-all we have today? I would rate it as a nice-to-have, but not need-to-have.

I would personally consider restrictions to be much more valuable than nice-to-have :slight_smile:.

For example, I think pure functions in a JS codebase help a little with maintainability, but I think they help immensely more in a language like Elm where all functions are pure, so I spend zero brain energy thinking about whether my functions are pure. I get the benefits with no mental overhead.

Another example could be automatic memory management. Sure, a language like C allows you to write correct programs with no memory bugs, but that requires a significant cognitive investment to achieve. Removing the possibility of use-after-frees, etc frees up our brains to focus on other things.

Flexibility and power come with the cost of cognitive overhead. Sometimes that cost is well justified. Other times, it's worth reclaiming a significant amount of cognitive bandwidth.

Bryce Miller (Aug 01 2026 at 20:37):

Richard has a talk that heavily influenced my thinking around the idea of limitations as superpowers. Maybe "Functional Programming for Pragmatists"?

Jasper Woudenberg (Aug 01 2026 at 20:39):

I think it would be nice for platform authors to learn from each others so good APIs can be shared. Maybe in some cases the pure bits of successful APIs could be merged into the standard library, standardizing them. But other than that I think it's hard to know upfront when API consistency between platforms is good vs. when it gets in the way of providing the optimal API for a particular domain, so it makes sense to me to let platform authors to be quite opinionated. Besides, switching platforms essentially comes down to switching domains, which involves a lot of learning (including of different APIs) in other languages too!

For me too the idea of working and maintaining a platform does not seem super appealing to me, except maybe as a temporary escape hatch or for bigger companies. I do imagine someone will write a platform that provides the typical set of APIs you find in other general purpose programming languages, for those that prefer to have a lot of low level control in Roc. But if platforms are a success, and I hope they will be, I would expect most will prefer to pick an opinionated platform if the developer experience is good enough.

Kasper Møller Andersen (Aug 02 2026 at 06:26):

Bryce Miller sagde:

Kasper Møller Andersen said:

The question is: how valuable is it to have a nice and restrictive platform API compared to the free-for-all we have today? I would rate it as a nice-to-have, but not need-to-have.

I would personally consider restrictions to be much more valuable than nice-to-have :slight_smile:.

For example, I think pure functions in a JS codebase help a little with maintainability, but I think they help immensely more in a language like Elm where all functions are pure, so I spend zero brain energy thinking about whether my functions are pure. I get the benefits with no mental overhead.

Another example could be automatic memory management. Sure, a language like C allows you to write correct programs with no memory bugs, but that requires a significant cognitive investment to achieve. Removing the possibility of use-after-frees, etc frees up our brains to focus on other things.

Flexibility and power come with the cost of cognitive overhead. Sometimes that cost is well justified. Other times, it's worth reclaiming a significant amount of cognitive bandwidth.

I don't see how any of that relates to platforms though? If I were to write some framework in Roc, on top of whatever platform, the framework still defines which functions must be pure and which can be effectful. The only difference between having this in the platform versus on top of the platform, is that when the framework sits on top, you can write code around the framework. But such code cannot participate in the framework, so I assume it must be only small bits and pieces that can somehow be passed to the framework still.

In other words, you could write an Elm-like framework inside your Roc application (without using an actual platform), and the restrictions you want will apply just as well there as they would if the framework was inside the platform. Because even though you can technically write any Roc code you want, with whatever effects you want, that code cannot participate in the framework, because the framework requires purity.

Kasper Møller Andersen (Aug 02 2026 at 06:34):

Jasper Woudenberg sagde:

I think it would be nice for platform authors to learn from each others so good APIs can be shared. Maybe in some cases the pure bits of successful APIs could be merged into the standard library, standardizing them. But other than that I think it's hard to know upfront when API consistency between platforms is good vs. when it gets in the way of providing the optimal API for a particular domain, so it makes sense to me to let platform authors to be quite opinionated. Besides, switching platforms essentially comes down to switching domains, which involves a lot of learning (including of different APIs) in other languages too!

I don't see having an opinionated API as being in opposition to having a general API. For one, I think we can aim to have general APIs for networking, files, etc., because we've seen those a 100 times over by now. We maybe need to figure out how the Roc version of those should look, but once we have that, they shouldn't differ between platforms. This is how Rust, Go, Java, everyone does it pretty much, and it works quite well. So platforms should have a way of hooking into those general APIs, like "this is how I provide the Files API". But any platform is free to offer more APIs than that, or not provide the general API at all. But for the case where the general API applies for a given platform, the platform should supply it.

Bryce Miller (Aug 02 2026 at 13:36):

Ahh sorry I probably picked a poor example :sweat_smile:. Basically, I’m intrigued by the design possibilities that come from the super hard API boundary between the platform and application. Just like enforced function purity, memory safety, etc have benefits, I’m curious what benefits I could provide by building the right limitations into a platform.

Bryce Miller (Aug 02 2026 at 13:44):

For what it’s worth, there’s the http package which defines Request and Response types, and is used in basic-webserver. I think the goal was that platforms could use packages to share types for common things like HTTP, etc.

Kasper Møller Andersen (Aug 02 2026 at 16:13):

No worries. I just happen to think this trade-off is likely quite similar for any framework which could ostensibly have been written in pure Roc. Which I think is most of them :blush:

Last updated: Aug 12 2026 at 12:35 UTC