How does Roc plan to deal with multicore processors? I haven't seen anything about this so far, and it seems like it challenges the division of program into app and platform. Using multiple cores most effectively seems like it'd need to be accounted for in the design of functions themselves, and so should live at the app layer, but is also extremely hardware dependent and so should live at the platform level. With performance being a key design req of Roc, this seems important, yet dealing with it in a manner functional, ergonomic, and transparent, sounds like a hell of a design challenge.
Obviously, this is triply the case for GPUs. Maybe Roc has no intent of supporting GPU compute, but that sounds odd for a language priding itself on separating out the platform as a first class language feature. If Roc could run in browser, on a windows desktop, and a bare metal Raspberry Pi, not working on GPU would be such a glaring exception for a performant language.
Not that I'd expect GPU support anytime soon - even if the design challenges get solved, it sounds like it'd take a hell of a lot of work to actually implement.
I don't think roc every has any explicit plans to support running on the GPU. That is a completely different model that likely would not fit the language.
As for multicore. That is essentially all up to the platform. We of course have to give some design support around what apis are possible and some sort of memory managment solution, but past that, a platform would define the primitives they want
For a web server fore example, it probably will not directly expose multicore to roc at all. It would just spawn a roc worker per thread instead.
So roc would have no idea that it is running in a threadpool
For more complex applications where Roc controls the parallelism, the platform will have to expose the api that the roc app depends on.
We have not fully decided how reference counting should work in multicore, but we will enable roc values being shared between threads, hopefully in a way that doesn't lead to much pessimization of thread local perf.
Yeah that's kinda what I expected. I just wasn't sure what had been chosen and acted on.
Last updated: Jul 06 2025 at 12:14 UTC