Hi :wave: noob here.
Could someone please explain Roc's threading model to me? I couldn't find it the docs nor in any of the talks.
Roc doesn't really have one
It is up to the platform
There has been more discussion on this somewhere here in zulip. The Task as builtin proposal which will happen has points on this also.
(Correct me if I'm wrong pls) That would create a unified Roc api to ask for concurent execution of tasks from the platform (Roc could specify like: "when all 5 of these tasks are done (I don't care about the order), do this next task"). But yes, implementing it is still up to the platform, not up to Roc and the platform can choose to just execute those tasks on the same thread one after the other, so there is no guarantee they'll run in parallel.
Yeah, roc can define a nice API, but that really doesn't say much about the underlying threading model. Technically speaking a platform could suspend roc execution at ever !
and move the roc application to a different core. Could theoretically even increment the refcount of everything in the task closure capture, store the state and have something to rewind back to.
Arguably, roc platform could expose an API to spawn threads for bulk compute tasks (i.e. give it a closure, await for completion). Naturally, you would not be able to communicate with the thread while it is doing its thing, so it would be fairly limited. The most natural way to achieve threading that makes sense for real work would be to target something like Lunatic runtime which can emulate CSP for wasm binaries. Might be a fun thing to do as well, given that Lunatic is inspired to some extent by Erlang VM, it would be fitting to run a modern FP language on a modern version of bean VM=))
More info here https://crates.io/crates/lunatic
Last updated: Jul 06 2025 at 12:14 UTC