Samuel (Sep 13 2026 at 08:52): Samuel (Sep 13 2026 at 08:52):Hi, I know that the 0.1.0 release won't include any concurrency or parallelism primitives and that everything will be sequential, but based on the available information, it seems that support for concurrent programming in a future Roc version is a given. My question is: why? For some reason, I assumed that the language could be completely sequential and that any kind of concurrency or parallelism would be implemented in the underlying platform. For example, the basic-cli platform currently doesn't support sending multiple HTTP requests at the same time, but what's stopping me from adding a new send_multiple! function that takes a List of Request? Why is this approach worse compared to having concurrency primitives directly in the Roc language? I'm obviously missing something.
Scott Campbell (Sep 13 2026 at 10:28):Compose-ability & performance.
A "internet of things" platform author... would have no idea about the application specifics requirements...
A "internet of things" app author... would want the performance benefits and flexibility to compose effects how they see fit... instead of blocking sequentially, if there was no bulk/batch apis etc.
They may want to do 3 things concurrently...
1) write a file to disk
2) wait for a hotplate to reach the desired temperature
3) send a web api request, which may have a 2nd waterfall request depending on response...
Of which, these could have dependencies, and block sequentially on waiting for the previous effect result... and some others may not have dependencies, and can be done independently & concurrently... It depends on the application specific requirements...
"Just compose this effect pattern at the platform layer and make this a single zig host effect"
While true, that's a possibility... there are more granular & ergonomic apis to get the job done (in theory).
Would want to avoid adding extra platform apis for application specific effect patterns. And there is also the issue of interleaving impure and pure code... if you want to have a pure mapping function between each effect.
"Ah stuff it... i'll just do the pure function in zig too, as one big mega effect."
And it could become tedious adding new platform apis for each use-case.
Tbh, I'm looking forward to the concurrency apis, when they land.
Richard Feldman (Sep 13 2026 at 13:09):Samuel said:
I'm obviously missing something.
you're right that it's possible to do effects concurrently (with whatever parallelism is desired) using platforms already - but platforms can't offer those things as pure functions :smile:
Richard Feldman (Sep 13 2026 at 13:10):so for example, a parallel version of List.map can only be implemented by a platform author as an effectful function
Richard Feldman (Sep 13 2026 at 13:10):to offer a pure function version of that, it needs to be in the builtins, but it also needs to coordinate with platforms behind the scenes (since they are responsible for implementing the concurrency primitives)
Richard Feldman (Sep 13 2026 at 13:11):and similarly, at that point you also have demand for "run these two pure functions concurrently" which would need similar treatment etc.
Last updated: Sep 24 2026 at 15:59 UTC