Calancea Daniel (Jul 05 2023 at 12:32): Calancea Daniel (Jul 05 2023 at 12:32):I will start by the fact that I am not a big fan of JS and never used the async/await constructs in a complex real-world application, but I can tell from the fact when I have to read JS from time to time, that the approach is a mess. I saw in a few demos usage of async/await model and it was interesting to me if you want to pursue that path also. Elm uses it because it is ultimately constrained by the JS it is transpiled into, however in the case of roc you have full freedom of choice.
So my question is: is there a big advantage for using a async/await approach instead of a actor-based or a similar model?
Languages like go, that employ in their way the idea of passing messages around concurrent constructs seems to be very successful and from my personal experience of writing elixir in production (the processes from elixir work on same basis as actors) it seems a much better approach for designing systems and debug them.
Brendan Hansknecht (Jul 05 2023 at 15:23):I think the best answer is that roc doesn't really have a concurrency model and it is decided by the platform.
That said, we describe tasks in an async way in roc because there is no guarantee that they will be synchronous. Roc simply can not know and must pass continuations to the platform. How the platform runs after that is out of roc's control.
Brendan Hansknecht (Jul 05 2023 at 15:23):As for models like actor and such, a platform definitely could be designed to support that.
Brendan Hansknecht (Jul 05 2023 at 15:25):The platform could expose methods to create actors, pass messages between them, and set recovery policies.
Brendan Hansknecht (Jul 05 2023 at 15:25):The individual roc actors would likely interact with those methods in an async/await style. That said, it is not strictly necessary.
Brendan Hansknecht (Jul 05 2023 at 15:26):Also, in some platforms, it may be the case that roc is just defining pure functions that the platform parallelizes. So the roc app has no sense of concurrency at all.
Brendan Hansknecht (Jul 05 2023 at 15:27):Currently, Task is a userland construct and is not needed in anyway.
Brendan Hansknecht (Jul 05 2023 at 15:29):You have 2 options for returning data to a platform/requesting actions be done:
Calancea Daniel (Jul 05 2023 at 18:38):This is very interesting, I will read about what represents the concept of platform, as it seemed I missed out on it.
Thank you very much for the response!
Anton (Jul 07 2023 at 09:28):We also have a nice explanation of what a platform is on our wiki
Eric Rogstad (Jun 06 2024 at 20:35):I wonder how hard it would be to build a platform that's a wrapper around something like https://crates.io/crates/ractor
Eric Rogstad (Jun 06 2024 at 20:35):You would of course call it roctor
Brendan Hansknecht (Jun 06 2024 at 21:28):Interesting. Might be hard to figure out how to happily interact with the rust traits
Brendan Hansknecht (Jun 06 2024 at 21:29):That said, setting it up so that you have many roc "applications" that each define a single actor sounds quite plausible.
Brendan Hansknecht (Jun 06 2024 at 21:29):and could be really interesting.
Brendan Hansknecht (Jun 06 2024 at 21:29):So like more of a plugin setup.
Brendan Hansknecht (Jun 06 2024 at 21:29):Where you have a ractor system, but any number of the actors can be defined in roc.
Brendan Hansknecht (Jun 06 2024 at 21:30):For a standalone platform, I guess you would just need to have a stand alone roc actor that is launched at startup.
Brendan Hansknecht (Jun 06 2024 at 21:30):Seems doable once we have the effect interpreter version of tasks.
Mehmet (Dec 03 2024 at 12:41):Hello everyone,
I’ve been watching Richard's talks and I am fascinated by the language, especially how he markets the whole project. He describes Roc as a "functional Go" with simple build tools and blazing speed, though these aren’t the only aspects that make Go powerful. Personally, I think Go's main selling point is its concurrency model—simple enough for Average Joe yet powerful enough for enterprise-grade code.
That said, I’m trying to understand how Roc handles concurrency. From what I’ve gathered, Roc relies on platforms that decide on the concurrency model. These platforms are hardcoded Rust programs that function like frameworks. Is that accurate, or am I missing something?
I’m not well-versed in FP, but after deploying ZIO and Cats Effect services for the past three years, I’m familiar with _some_ FP concepts. One of the reasons I love ZIO is its concurrency model. It allows you to run stream computations and pure functions in parallel with a simple API call, like ZIO#withParallelism. Additionally, ZIO provides built-in concurrent data structures such as Hubs, Queues, and Streams.
I’m curious—how do these concepts translate to Roc? Does it offer similar abstractions or tools for concurrency, or is its approach fundamentally different?
Unrelated to my previous question but from what I’ve gathered, the Roc compiler will not be bootstrapped and will always depend on Rust. I assume the same would apply to platforms as well. Do you think this could cause issues if the language grows significantly? It seems that extending the language or writing frameworks for it would require knowing Rust as well, which doesn’t feel very ergonomic to me.
Anton (Dec 03 2024 at 13:01):Hi @Mehmet,
Roc relies on platforms that decide on the concurrency model
That is correct
These platforms are hardcoded Rust programs that function like frameworks.
Platforms can use any language that supports the C ABI, we have platforms in zig, rust, go... Interop with python, java, javascript is also possible. There are some important differences with frameworks, take a look here for the full explanation.
Anton (Dec 03 2024 at 13:03):Roc compiler will not be bootstrapped and will always depend on Rust.
Always is a long time but yes, most of it will be written in Rust for the foreseeable future
Anton (Dec 03 2024 at 13:07):It seems that extending the language or writing frameworks for it would require knowing Rust as well
Things like a web framework can use existing platforms like basic-webserver and be written in pure Roc. In case your framework is a game engine, it seems easier to connect an existing game engine with Roc compared to writing it from scratch :big_smile:
Anton (Dec 03 2024 at 13:13):Can you share some specific use cases that require "extending the language"?
Anton (Dec 03 2024 at 13:18):It allows you to run stream computations and pure functions in parallel with a simple API call, like ZIO#withParallelism.
Running effects (e.g. multiple web requests) in parallel will be possible, I'm not sure about pure functions.
Anton (Dec 03 2024 at 13:18):built-in concurrent data structures such as Hubs, Queues, and Streams.
I think we've talked about that in the past but I don't recall any specifics
Mehmet (Dec 03 2024 at 13:19):Anton said:
Can you share some specific use cases that require "extending the language"?
A cunning Go programmer can directly contribute to the language's development, but to contribute to Roc's development, one also has to learn Rust.
Anton (Dec 03 2024 at 13:21):Yes, this is likely to stay this way. With Rust we can achieve maximum performance.
Anton (Dec 03 2024 at 13:23):Contributing aside, it's definitely our intention that people do not need to learn a language like Rust to get things done with Roc.
Mehmet (Dec 03 2024 at 13:32):Anton said:
Things like a web framework can use existing platforms like basic-webserver and be written in pure Roc.
My main concern is more about marketing than engineering. Nowadays, if you look at Scala job listings, they specifically ask whether you know ZIO, cats-effect, pekko, or any other shiny tool that type astronauts have recently come up with. Scala's market share is already small and now you have different competing ecosystems, which makes it hard to pitch Scala to a CTO. On the other hand, Go provides a default concurrency model and a good web stack with net/http.
A web application also needs to connect to a message bus or a database, which requires some concurrency model as well. From what I gather, basic-webserver should also provide these features so that when they are combined, the effects can just click. This feels like exactly what Scala did wrong in the past because someone will inevitably come up with a competing platform in the future. I am probably missing something and definitely need to delve deeper into the documentation.
Anton (Dec 03 2024 at 13:38):So do I understand correctly that the core of the problem is that; with our current setup we encourage too many ways to do the same thing?
Mehmet (Dec 03 2024 at 13:43):Yup, at least this is what it feels like after taking a look for couple of hours.
Although don't get me wrong, I hope you wonderful people succeed in this endeavor. Functional programming truly needs a marketable language that doesn’t cost a fortune to run on the cloud unlike JVM-based languages, and is simple enough to make it pragmatic for both recruitment and cost considerations.
When I was at uni, it felt like Scala was that language. However, ten years later, it feels like Scala has failed. I just hope Roc will learn lessons from languages like Haskell, Scala and OCaml on why they failed to gain mainstream attention, whereas Go succeeded.
Anton (Dec 03 2024 at 14:33):I was also using Scala ten years ago :)
Anton (Dec 03 2024 at 14:43):we encourage too many ways to do the same thing?
It's definitely something to watch out for although my current feeling is that platforms help prevent that. It seems likely that people will build new things on top of an existing well tested platform or modify it instead of starting from scratch.
Last updated: Jul 06 2025 at 12:14 UTC