The one thing that is keeping Erlang, Elixir, Gleam in the spotlight is the actor based concurrency and distributed computing capabilites of the Erlang VM on on-prem hardware
I propose a concurrency model, where the Roc platform abstracts the difficulties of shared data between threads and processes and on top of that sockect communication.
I dont have enough knowledge in Rust to implement this but there are a lot of orgs out there who are dependant on on-prem systems for their work\
I have not seen any concurrency discussion other than the Tasks and async.
Even though at the single thread level, async is the best concurrency mechanism, we would be foolish to let go of the remaining cores on modern hardware.
Guten-tag
In this case, roc is quite interesting. Concurrency is essentially completely up to the platform. As such, if it makes sense, a platform can expose an actor model to Roc.
If, on the other hand, the app is just a basic web server, it may be the case the the platform does not directly expose any concurrency control to the app. It may just implicitly spawn the roc app in parallel for each request.
I really think any level could be supported here. May take a lot of thinking and wrapping on the platform side to create a nice API, but i don't think that concurrency is something (for the most part) Roc needs to directly handle or think about.
As an aside, some of the async work has been setup on multicore. It is still very much in it's early days, but i have an example webserver that uses many cores and the roc app is just written in a standard async manner.
I'm interested in using actors for editor plugins. If anyone wants to try to set up a rust actor platform -with for example rust actix- it would be a valuable project.
gleam's typed otp may be a great resource for such a platform https://github.com/gleam-lang/otp
Interesting, for the editor plugins specifically, we would need it to be written in rust because there can only be one platform.
Last updated: Jul 05 2025 at 12:14 UTC