TeaDrinkingProgrammer (Feb 01 2026 at 14:59): TeaDrinkingProgrammer (Feb 01 2026 at 14:59):I've been thinking lately about how you would integrate external libraries in a platform in a nice way.
Say for instance that I want to encode some video in an REST API. Ideally, you would use a Roc library, but for now, nothing beats FFMPEG. Logically it belongs in a platform, but it doesn't belong specifically in the basic http platform. You could fork it and add it yourself but that gets tedious.
The other problem with this use case is you can have endless combinations: package A with B, B with C, A with C etc. This makes compiling specific versions of the platform practically impossible.
The only solutions I could come up with is some kind of plugin system that uses the package manager of the platform, but this means users need to manage two package environment and have knowledge of the platform in order to compile it.
What are your thoughts on this?
Rick Hull (Feb 01 2026 at 15:03):I think that taking a base platform and adding your lib is quite sane. Whether that means forking a standard roc platform or not, probably! It doesn't seem too tedious to me. We could add some UX/DX automation/framework to make this simple?
I did this with schnorr-platform, based solely off of roc-platform-template-zig, not even basic-cli.
My sense is that platform development is hard. But we can make it relatively easy.
Jasper Woudenberg (Feb 01 2026 at 21:12):I think there might also be really nice designs here that would not require a "one-off platform". I understand you're trying to make a general point, but looking at your specific example for a moment: encoding a video directly in a request handler has some big downsides and we can do better: putting the encoding task in a queue and have a sepate worker process take encoding tasks of the queue would prevent the service from locking up if a couple of people decide to upload a video at the same time.
So instead of adding video-encoding support to an http platform, maybe the encoding could be done by another Roc application written in some "job-queue" platform that's provides a great toolset for calling external tools like FFMPEG. Seen this way, video encoding not being easily accessible in the http platform is a feature: it steers programmers towards a better solution!
While I think that for this particular example things might work out quite well without a custom platform, it is kind of hard to know how well it will generalize to other types of problems because as far as I'm aware it's not been tried before. I think it's a really cool experiment, one of the things that personally excites me most about Roc. If this community manages to create these super-smooth platform experiences for different domains that at the same time don't hem people in, that's going to be huge!
Niclas Ahden (Feb 02 2026 at 09:21):FWIW I have done exactly this in Roc for a video platform and +1 to what @Jasper Woudenberg is saying :)
I used basic-cli for the job worker process and Cmd to call the CLI-version of ffmpeg. I thought about a custom platform but opted not to due to the small difference it’d make in my case.
If there was a platform which wrapped the ffmpeg library and others I would have used it. However, how would you maintain a platform which wraps many libraries and their different versions? At one point there was a discussion of “feature toggles” on platforms. Platform authors could then support as many features as they want, while the user doesn’t have to include all of them in their application. Perhaps that’s a solution to the “job processing” platform’s support matrix (choosing ffmpeg vX and Y vZ).
It’ll be interesting to see how the platform ecosystem evolves :)
Tobias Steckenborn (Feb 02 2026 at 11:31):Yet that's to me still a very valid discussion. Currently if nothing Roc native is available, that could lead to a lot of forks from a lot of platforms just to add a single outside dependency (or combination of such), which could lead to quite some fragmentation
Niclas Ahden (Feb 02 2026 at 12:05):I think we simply have to try it and not shy away from experimenting in different directions. It may intellectually seem one way but practically turn out differently.
So far I’m using four platforms: basic-cli, basic-webserver, joy for web front-end, and a custom platform for a WoW bot which I wrote for fun (could have used basic-cli). These few platforms have allowed me to write 75k LOC in numerous applications to meet actual client needs. I’ve made extensions to cli and webserver, but nothing that couldn’t be upstreamed. This tells me that a surprising number of use-cases are already covered by these simple platforms, despite their small API surface. We will clearly need more platforms than that, but I don’t think enough people have actually experimented with that based on real practical need yet.
Niclas Ahden (Feb 02 2026 at 12:08):PS. Not trying to say it’s not a valid discussion, clearly it’d be great to have ideation around this topic!
Romain Lepert (Feb 02 2026 at 15:56):This general concern is pretty much what Components/Worlds solves for WASM
https://youtu.be/_HdV5eCUaRw?si=z0hHK5paE3lECemQ&t=945
I am sure there is a lot to learn from there
Dan G Knutson (Feb 02 2026 at 20:15):I like the idea of using separate 'bag of effects' types to solve this in a general-purpose platform, too.
Like if you have a web framework platform intended to be used with a heroku/fly/render-like platform, you could offer two entrypoints with different arguments passed from the host for the http handler and a background job handler, and maybe the background job handler either gets passed some function pointers including ffmpeg bindings, or it gets some more generic shell access (that you could sandbox as an app author).
Basically what Jasper said, but you can also offer an all-in-one platform still (via entrypoints and bag-of-effects records) if that's the goal.
Brendan Hansknecht (Feb 03 2026 at 05:27):We definitely could explicitly add "platform" libraries or something of that nature that are very explicit (such that users know they are adding new effects) and then those libraries depend on loading shared libraries. That would give the flexibility
Another essentially equivalent option but with more wrangling/slightly worse ergonomics is for platforms to wrap libffi. Then they can let any roc library load a shared library and create effects. That would enable platforms to opt into the ecosystem of shared libraries.
Either of those would work to have a generic platform that can add ffmpeg. The main cost being the platform could no longer be 100% static. It would depend on loading shared libaries that need to be someone that the app can access.
Last updated: Jun 16 2026 at 16:19 UTC