Michael Stevens (Oct 23 2025 at 13:42): Michael Stevens (Oct 23 2025 at 13:42):Hey all, I'm new to Roc, the separation between platforms and applications is a really cool idea.
I watched a talk about how Roc's implementation of effects is essentially that the function returns a result object with something indicating what effect should be performed and then that is implemented elsewhere. I'm wondering, is it possible for the platform to expose custom effects to the application that only the platform can handle?
At work I use a workflow service like cadence / temporal for orchestrating distributed, long running jobs. To use it correctly devs essentially have to write pure functions. Anything producing side effects has to be called in a special way so the workflow library can manage them. If you don't you'll get wierd behavior at runtime.
Turns out getting everyone to use this thing correctly consistently is impossible. With something like Roc though, I could imagine a framework that could statically catch those problems. For it to work though I think the platform would have to be able to expose some set of effect types that it can manage execution for and then resume running Roc code once the effect result is available.
Hannes (Oct 23 2025 at 14:16):the platform to expose custom effects to the application that only the platform can handle
platform would have to be able to expose some set of effect types that it can manage execution for and then resume running Roc code once the effect result is available.
As far as I know, that is exactly how Roc works! All effects in Roc are handled by the platform, and then it hands the return value of the effect back to the application
Hannes (Oct 23 2025 at 14:17):Let me know if I've misunderstood your question :sweat_smile:
Michael Stevens (Oct 23 2025 at 15:40):So it's possible to write something like
result0 = ctx.run!("foo")
result1 = ctx.run!("bar", result0)
Where there's like an hour long gap between the two results where the platform is busy running task "foo"?
Jasper Woudenberg (Oct 23 2025 at 17:07):Such a cool idea combining Roc with Temporal, I think that'd be a great fit!
I think what you describe should be possible. One way to go about it would be for the platform to keep track of results from previous effects, serialize and store them. Then when the "current effect" resolves the platform can rerun the function, return stored results from effect calls, and when a new effect is encountered queue it and exit. The platform would keep doing that until the function can run off stored results to completion. Because the platform is fully in control of what effects are possible and Roc is otherwise pure there'd be no way for users to do anything illegal.
Michael Stevens (Oct 23 2025 at 19:15):It does seem like a perfect fit. We have another problem where when we push new versions of our service if we aren't extra careful inflight workflows will have unexpected behavior as they start to run on the new code.
You can solve that with workflow versioning, but that's another footgun that goes off all the time.
Could I keep multiple versions of the roc application around and always run requests on the same version they started on?
Brendan Hansknecht (Oct 23 2025 at 19:52):For sure
Brendan Hansknecht (Oct 23 2025 at 19:52):They are just binaries
Michael Stevens (Oct 23 2025 at 20:14):Are there any examples of platforms in go/rust/zig that are slightly more complicated than this one? https://roc-lang.org/examples/GoPlatform/README
Brendan Hansknecht (Oct 24 2025 at 02:27):Slightly, maybe not, significantly, probably.
Brendan Hansknecht (Oct 24 2025 at 02:27):We have basic cli and basic webserver in rust
Brendan Hansknecht (Oct 24 2025 at 02:27):We have this like roc wasm4 in zig
Anton (Oct 24 2025 at 08:15):Some links:
https://github.com/roc-lang/basic-cli
https://github.com/roc-lang/basic-webserver
https://github.com/lukewilliamboswell/roc-wasm4 (this one is not up to date)
Last updated: Nov 09 2025 at 12:14 UTC