Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'FRP', the actor model, and the Signals project #11

Closed
kellytk opened this issue Oct 8, 2019 · 1 comment

Comments

@kellytk
Copy link

@kellytk kellytk commented Oct 8, 2019

I've had a thought recently: The actor model is a hack to handle concurrency that becomes obsolete with proper tools to address concurrency's issues such as async/await, Futures+runtime, and other language and ecosystem synchronization features.

I'd be interested to see actor-style supervision hierarchies, ('self-healing') first-class, generalized and ordered communication (messages) between [local/remote] actors, and eventual-consitency state (eg., raft) as separate Future-based crates which do not assume an actor model.

Is there any particular reason why experiments of the above kind couldn't be performed together with the Signals project if one wanted to stay close to Futures whilst writing code in an 'FRP' style?

@Pauan

This comment has been minimized.

Copy link
Owner

@Pauan Pauan commented Oct 14, 2019

I think actors and signals are basically completely unrelated. FRP is also completely unrelated to actors, it's a different paradigm entirely.

An actor is basically just a Sink which allows it to receive messages. That's pretty much it.

I think Streams are a lot better than actors. They're simpler, and composable.

All of the things you mentioned are things that would be handled by Stream, not Signal (it doesn't really make sense to talk about them for Signal).

Here is an example of a supervision hierarchy with Streams:

loop {
    let result = spawn_some_task().try_for_each(|message| {
        // Handle message...
    }).await;

    match result {
        Ok(()) => {
            // The task finished and did not error...
            break;
        },
        Err(e) => {
            // Handle error from task...
        },
    }
}

The above loop will keep respawning the subtask if it fails.

As for "first-class, generalized and ordered communication", that's exactly what Stream is. It sounds like you're not really looking for FRP, you're looking for streams.

@Pauan Pauan closed this Oct 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.