async platforms? · beginners · Zulip Chat Archive

Hello everyone, I'm new here and just finished reading about the platforms in the documentation website
It seems roc platforms would be a good fit for asynchronous io
Does one exist? Or is there a proposal for one?

Richard Feldman (Jun 15 2026 at 22:58):

welcome! The short answer is that platforms are already able to do async I/O, but implementing it with good performance is very advanced and we don't have a good example of doing it end to end yet :smile:

souf (Jun 16 2026 at 05:15):

@Richard Feldman we could have some implementation in roc, for example an event loop implemented in roc directly?

Raz (Jun 16 2026 at 08:10):

@souf that sounds backwards, I imagined the platform implements the event loop but only exports functions like gather, race, etc

souf (Jun 16 2026 at 09:22):

@Raz why would it be backwards?

souf (Jun 16 2026 at 09:23):

Having the platform doing it would require each platform to re-implement it, and potentially more complex types to make it ergonomic and compatible with a wide range of async operations/erros, etc... between the platform and roc. Having roc doing it, it would probably be simpler, and you gain compatibility with all platforms by doing it once and less platform specifics.

souf (Jun 16 2026 at 09:51):

What I think is that the platform could expose something like that:

## Spawns a function returning `a` future that can be awaited
run_async! : (() => a) => Future a

## Waits for at least one of the given futures completes.
##  returns the future that completed and its value.
wait_any! : List (Future a) => (Future a, a)

wait_any rather than just wait otherwise you would not be able to implement race efficiently.

From here, race, all, etc... is just pure logic around it.

souf (Jun 16 2026 at 09:57):

Not sure what it involves as I haven't worked with platform yet thought, but I'm very interested in having such a feature.

souf (Jun 16 2026 at 10:13):

Actually with this approach there is a loop in Roc, and potentially one in the underlying platform calls (that does the optimized waiting). So I'm not even sure how to call this. Is the roc part supposed to be called an "event loop"?

Luke Boswell (Jun 16 2026 at 11:06):

I asked Claude to do some exploration and give a summary based on old discussions here in zulip... I'm not sure this is super accurate as it's been a while since we've talked about this or done any experiments but it mostly looks ok to me https://gist.github.com/lukewilliamboswell/304c57045fa0116c1a94a1baddcaf469

Richard Feldman (Jun 16 2026 at 13:03):

yeah I'd say the "Mechanism 1" section is the most relevant - that prototype it links to is how we can have a Go-style experience of "I/O is automatically nonblocking without needing to write async or await"

Richard Feldman (Jun 16 2026 at 13:04):

I think it's better overall than actual async/await both because it gets rid of the ceremony of writing "async" and "await" all over the place (while still getting you the concurrency benefits) but also because you get real stack traces without having to pay an insane up-front performance cost

Richard Feldman (Jun 16 2026 at 13:05):

it's already possible today to implement a host that does this, but it's a lot of work :smile:

Richard Feldman (Jun 16 2026 at 13:06):

I want to work on that sometime after the 0.1.0 launch (which is on track to be later this year)

Richard Feldman (Jun 16 2026 at 13:06):

because separately from the host stuff to get the nonblocking I/O, we do actually need some compiler changes to be able to do the equivalent of a type-safe Promise.all from JS

souf (Jun 16 2026 at 13:07):

Richard Feldman said:

you get real stack traces without having to pay an insane up-front performance cost

why would the performance cost be so big?

Richard Feldman (Jun 16 2026 at 13:07):

so I want to do that work together with the host work and have concurrency be a major theme of the 0.2.0 release

Richard Feldman (Jun 16 2026 at 13:24):

souf said:

Richard Feldman said:

you get real stack traces without having to pay an insane up-front performance cost

why would the performance cost be so big?

without going too deep down the coroutines rabbit hole:

the way we'd implement this is essentially "pick a chunk of memory and tell the OS to use that as a real, totally normal stack, then after we kick off nonblocking I/O operations, our scheduler tells the OS to go switch over to a different stack that we switched away from earlier, so we're able to keep doing useful work while the I/O operation is waiting on the network or whatever. Then eventually the scheduler switches the stack back to the original one sometime after the I/O operation finished, and that work can continue as normal."
if you want to get a stack trace at any point there, it's trivial. You have a real, normal stack! So you just do the normal thing and it works as normal. No extra cost.
async in Rust is the fastest implementation I know of (e.g. it's lower overhead than how JS does it) and it's totally different. You don't have real stacks, you have a state machine that determines what to do in between the I/O operations. As soon as you get to an I/O operation, your real call stack stops being a useful history of what calls happened in what order.
this approach has some flexibility upsides, but a major downside is that if you ask for a stack trace, what you get is "stack trace going back to the last I/O operation" rather than a full stack trace.
it's impossible to recover the stack information after the fact. If you want a full stack trace with all the info you'd normally get, there is only one possible way to do it: every time you do an I/O operation, you defensively go walk the entire stack and write down the entire trace somewhere in memory just in case you want to access it later
you have to pay this cost on every I/O operation even if the app never actually needs a stack trace, ever. Because this is so expensive, it's common to not do it and just have bad stack traces in async world. Or you pay the performance cost and can recover the normal-looking traces you get for free with the other approach.

Richard Feldman (Jun 16 2026 at 13:26):

so I think for us, the "stackful" approach is better.

Richard Feldman (Jun 16 2026 at 13:27):

separately, there's the question of how to hook into hosts that are using async, such as JS in the browser where effects like http requests are unavoidably async even if that's not what we're compiling directly to

Richard Feldman (Jun 16 2026 at 13:32):

in general, it's possible for us to do this stackful coroutines approach and then hook into the host's async machinery. On non-wasm targets, this can theoretically be pretty fast, although we'd need a working implementation to properly verify that.

On wasm, it's currently possible but slow because wasm's stack switching proposal (which was in Phase 2 last I checked) hadn't landed yet https://effect-handlers.org/talks/stack-switching-wasmcg-feb2025.pdf

souf (Jun 16 2026 at 13:49):

Thanks for the nice explanation! Is that related to the fact that rust requires to pass a cli flag explicitly to enable stack traces?

Richard Feldman (Jun 16 2026 at 14:49):

I don't think so, actually

Richard Feldman (Jun 16 2026 at 14:50):

I think that applies to synchronous code, and I suspect it's more about whether there's a signal handler set up that collects backtraces on stack overflows (and other OS signals, like segfaults) as opposed to just doing the default thing of exiting (which might be what you want, in case for example your program is setting up its own signal handling and you don't want Rust to inject its own signal handling that could interfere with that)

Romain Lepert (Jun 16 2026 at 19:16):

Richard Feldman said:

in general, it's possible for us to do this stackful coroutines approach and then hook into the host's async machinery. On non-wasm targets, this can theoretically be pretty fast, although we'd need a working implementation to properly verify that.

On wasm, it's currently possible but slow because wasm's stack switching proposal (which was in Phase 2 last I checked) hadn't landed yet https://effect-handlers.org/talks/stack-switching-wasmcg-feb2025.pdf

WASI 0.3 is all about the Component Model's async ABI
https://bytecodealliance.org/articles/WASI-0.3
https://github.com/WebAssembly/component-model/blob/main/design/mvp/CanonicalABI.md#concurrency

So it seems to made quite some progress.