14 ms·

Show HN: Coerce – Actor runtime for Rust using async/await and tokio channels

155 points by ljph 7y ago

artfulhippo 7y ago
Cool. And good thing you open sourced it now, before you built failover strategies (e.g. supervision) — you still have time to change the name.
- tunesmith 7y ago
  Coerce is often misused to imply encouragement or persuasion - but it specifically means to engage the efforts of others through violence or threat of violence. It's an ugly word.
xiphias2 7y ago
Isn't async-std interface the future of async at this point? It seems that there's still a huge split inside the community between async-std and tokio interfaces that should be resolved ASAP. Is there some working group to help standardizing the interfaces and upgrade tokio based apps to the standard?
- swsieber 7y ago
  No, it's not the standard. There has been some friction between the two groups (tokio and async-std) unfortunately. I'm not sure what the original source of friction was, but bad feelings seem to seep out when the projects are discussed in active Rust communities. I wonder how long the drama will go on. But at least both parties seem to be trying to be civil about it (and succeed).
  - bluejekyll 7y ago
    Folio => Tokio
    - swsieber 7y ago
      Argh. Thank you. I caught that autocorrect once but then reworded things.
    - estebank 7y ago
      Now that is another nice name in search of an async/await project.
- zozbot234 7y ago
  There's nothing "standard" about async-std as of yet. The name is because it tries to build something that can be used just like std library facilities, except for the async support.
  - Argorak 7y ago
    You are right, but I also want to point out that we fully buy into the futures-rs interface over custom implementations.
- oconnor663 7y ago
  > should be resolved ASAP I'm not sure having multiple runtimes is such a problem. The Rust async IO model was explicitly designed to accommodate different runtimes. There are a lot of tradeoffs around how a runtime does multi-threading, for example, and embedded systems may also do their own thing. Tokio vs async-std might or might not make sense as a long term split, but I think it's too early to say.
  - xiphias2 7y ago
    I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs) There's a bug for it in Tokio, but it's low priority as far as I know. https://github.com/tokio-rs/tokio/issues/1297 https://github.com/tokio-rs/tokio/issues/1297
    - steveklabnik 7y ago
      It's not particularly low priority https://github.com/tokio-rs/tokio/pull/1744 https://github.com/tokio-rs/tokio/pull/1744 (See the last section in particular)
      - xiphias2 7y ago
        Oh, so there's a pull request that I didn't see, the bugs don't show that it's being worked on. I understand that there are lots of hard technical issues to be resolved, it's just the visibility of this pull request wasn't that good. Thanks for the answer! Very interesting thread.
      - twic 7y ago
        This is a great thread! Lots of different perspectives on a difficult technical problem, plus appearances from many of my favourite Rust characters: we've got Ralf telling everyone that only abstract machines exist, boats turning up halfway through to contradict everyone, and Douman dropping by to offer the unhelpful C++ perspective.
    - Argorak 7y ago
      > I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs) There is a huge amount of complaints just fundamentally about async-std's existence, though.
- Argorak 7y ago
  The position of the async-std project is that people should use _futures-rs_ as the integration point and avoid integrating into tokio or async-std if possible. (both are IO optimised) Especially for things like an actor system, I would recommend to not use either, but instead spawn a dedicated number of threads handling the actors. This allows you to be specifically optimised to the problem. bastion is a great example for that. async-std ships a second library called "async-task", which implements just the task/future allocation component and allows you to quickly implement your own runtime. Full disclosure: I'm one of async-std's maintainers.
  - xiphias2 7y ago
    I understand this, but it still doesn't answer the main point: are you working together with tokio maintainers to move to futures-rs as soon as possible and even extend the interface of futures-rs more if needed? In my view the separate interfaces increase the long term damage that new libraries are creating every day, and it should be higher priority to resolve it together before implementing new features in either of the two libraries (async-std and tokio).
    - Argorak 7y ago
      We don't maintain futures-rs. But for the reasons you outline above (stability), our interface is also effectively done. The choice of not using all of futures for their interface is outspoken the strategy of tokio. We have encouraged them to prefer the futures layers, but we don't see the work happening. So, to answer your question: we are not working with them, the place of collaboration is futures-rs.
  - ComputerGuru 7y ago
    I have heard that using the async-std APIs (but not the reactor and executor) causes background futures to be spawned to the async-std specific executor. I’m not sure of the veracity of this claim, can you comment?
    - Argorak 7y ago
- Dowwie 7y ago
  Why should it be resolved ASAP? This mentality that there should be no more than one viable solution to address a need is what needs resolving. Rust would not even exist if enough people agreed with that sentiment.
bvelica 7y ago
Ok, for the uninitiated (i m still learning rust) why do we have this split? Thank you!
- steveklabnik 7y ago
  Which split are you talking about?
  - paulddraper 7y ago
    I'm guessing async-std and tokio.
bluejekyll 7y ago
I’m always excited to see people experimenting with different things. I wonder if the author could comment on how the goals of this project might differ from those of Actix? Many people are still new to async/await; did you consider add a runtime/executor in your readme example? I didn’t see the creation of a Runtime to drive the futures, that might be a nice thing to show.
- ljph 7y ago
  Hi mate, The goal is to eventually have actors spread across multiple servers with automatic load balancing etc. I'm currently working on remote actors, with the goal for the API to be exactly the same whether you're talking to a local actor or a remote actor - it shouldn't matter to the user! The runtime is just Tokio's runtime, actors are just tasks awaiting on messages (and handling them) from their Receiver! Cheers!
  - bluejekyll 7y ago
    Ah. Cool. What are your plans around data serialization and compatibility of different nodes during version upgrade? And thanks for the answer!
    - ljph 7y ago
      Regarding data serialization, I'm currently using serde_json, however that's just because it's easy to work with for development/testing purposes though I do love the idea of using protobufs! Node compatibility and I guess distribution overall are problems I'm extremely looking forward to tackling! :)
      - leeoniya 7y ago
        > though I do love the idea of using protobufs! or FlatBuffers!
      - samcodes 7y ago
        Not sure on rust compatibility, but have you considered Cap’n Proto? https://capnproto.org/ https://capnproto.org/
vertexclique 7y ago
Worth to mention that Bastion has been developed a lot and it has its own design(in simple terms SMP based executor) to leverage asynchronous programming (with fault-tolerant manner). It isn't dependent on any runtime. You can mix and use any runtime with it and supplies hierarchical reduction based concurrency. We proudly take Erlang's runtime model and implemented it in Rust. Moreover, we are currently working on distributed carrier protocol to make Bastion form a cluster, exchange data and recover from partial failures in distributed workloads too. Local failures are recovered and we have built-in lifecycle management. Maybe after these words you might want to take a look: https://github.com/bastion-rs/bastion https://github.com/bastion-rs/bastion You can write a fully fault-tolerant program with our macro mechanisms too: https://github.com/bastion-rs/fort https://github.com/bastion-rs/fort Here our distributed protocol repository: https://github.com/bastion-rs/artillery https://github.com/bastion-rs/artillery And our landing page: https://bastion.rs/ https://bastion.rs/
- asdkhadsj 7y ago
  I'm not familiar with this family of technology, so forgive the dumb question: But.. what is this? I read the landing page and browsed a couple examples and I have no clue what I would use it for. Would it be a pile of distributed workers handling jobs? Sort of like pushing a job into a job queue and having a bunch of workers consume jobs? If that's the case, what are some reasons I might choose this Bastion model over a more traditional JobQueue <-> Worker model? Thanks to any replies. I feel I should be interested, but I'm confused :)
  - deleted 7y ago
    [deleted]
  - vertexclique 7y ago
    As landing page states it is a runtime supplies actor-model like concurrency. If you are familiar with Erlang. Bastion is the reflection of the Erlang runtime in Rust. Far beyond an actor system implementation. It is a complete system with full asynchronous communication. "...It supplies actor-model-like concurrency with a lightweight process implementation and utilizes all of the system resources efficiently guaranteeing of at-most-once message delivery." It might be a single process, pile of workers, a bunch of http servers dispatching requests, various middleware layers connected with asynchronous boundaries. With all these built on top of crash and fault recovery. For more information what it provides please take a look to my latest presentation at Rust Berlin: https://slides.com/vertexclique/crash-course-with-bastion#/ https://slides.com/vertexclique/crash-course-with-bastion#/
staticassertion 7y ago
Nice. I tried building an actor library in rust, using proc macros. It ended up being super annoying to deal with generic actors. Maybe I'll just write a proc macro over this lib instead. * https://github.com/insanitybit/derive_aktor https://github.com/insanitybit/derive_aktor edit: Is this not on crates-io?
- ljph 7y ago
  https://crates.io/crates/coerce-rt https://crates.io/crates/coerce-rt :)
  - staticassertion 7y ago
    Thanks.
ProfHewitt 7y ago
Actors are explained here: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566
mmastrac 7y ago
This is pretty cool. We ended up building our own version of something like this internally last year, but I could see us tossing our code in favour of this. The big advantage to writing code this way is that you just don't need to write these actors thread-safe. They will only ever handle a single message at a time. For an async system it's really fast to get something up and running.
windor 7y ago
Read through the code just now.Thanks for the small but powerful project,I have tried to make something similar, but failed. The lib is very close to what I want to do actor-based programming in Rust. It would be great if actor can send message to itself.

155 points by ljph 7y ago

Cool. And good thing you open sourced it now, before you built failover strategies (e.g. supervision) — you still have time to change the name.

tunesmith 7y ago
Coerce is often misused to imply encouragement or persuasion - but it specifically means to engage the efforts of others through violence or threat of violence. It's an ugly word.

xiphias2 7y ago

Isn't async-std interface the future of async at this point? It seems that there's still a huge split inside the community between async-std and tokio interfaces that should be resolved ASAP. Is there some working group to help standardizing the interfaces and upgrade tokio based apps to the standard?

swsieber 7y ago
No, it's not the standard. There has been some friction between the two groups (tokio and async-std) unfortunately. I'm not sure what the original source of friction was, but bad feelings seem to seep out when the projects are discussed in active Rust communities. I wonder how long the drama will go on. But at least both parties seem to be trying to be civil about it (and succeed).
- bluejekyll 7y ago
  Folio => Tokio
  - swsieber 7y ago
    Argh. Thank you. I caught that autocorrect once but then reworded things.
  - estebank 7y ago
    Now that is another nice name in search of an async/await project.
zozbot234 7y ago
There's nothing "standard" about async-std as of yet. The name is because it tries to build something that can be used just like std library facilities, except for the async support.
- Argorak 7y ago
  You are right, but I also want to point out that we fully buy into the futures-rs interface over custom implementations.
oconnor663 7y ago
> should be resolved ASAP I'm not sure having multiple runtimes is such a problem. The Rust async IO model was explicitly designed to accommodate different runtimes. There are a lot of tradeoffs around how a runtime does multi-threading, for example, and embedded systems may also do their own thing. Tokio vs async-std might or might not make sense as a long term split, but I think it's too early to say.
- xiphias2 7y ago
  I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs) There's a bug for it in Tokio, but it's low priority as far as I know. https://github.com/tokio-rs/tokio/issues/1297 https://github.com/tokio-rs/tokio/issues/1297
  - steveklabnik 7y ago
    It's not particularly low priority https://github.com/tokio-rs/tokio/pull/1744 https://github.com/tokio-rs/tokio/pull/1744 (See the last section in particular)
    - xiphias2 7y ago
      Oh, so there's a pull request that I didn't see, the bugs don't show that it's being worked on. I understand that there are lots of hard technical issues to be resolved, it's just the visibility of this pull request wasn't that good. Thanks for the answer! Very interesting thread.
    - twic 7y ago
      This is a great thread! Lots of different perspectives on a difficult technical problem, plus appearances from many of my favourite Rust characters: we've got Ralf telling everyone that only abstract machines exist, boats turning up halfway through to contradict everyone, and Douman dropping by to offer the unhelpful C++ perspective.
  - Argorak 7y ago
    > I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs) There is a huge amount of complaints just fundamentally about async-std's existence, though.
Argorak 7y ago
The position of the async-std project is that people should use _futures-rs_ as the integration point and avoid integrating into tokio or async-std if possible. (both are IO optimised) Especially for things like an actor system, I would recommend to not use either, but instead spawn a dedicated number of threads handling the actors. This allows you to be specifically optimised to the problem. bastion is a great example for that. async-std ships a second library called "async-task", which implements just the task/future allocation component and allows you to quickly implement your own runtime. Full disclosure: I'm one of async-std's maintainers.
- xiphias2 7y ago
  I understand this, but it still doesn't answer the main point: are you working together with tokio maintainers to move to futures-rs as soon as possible and even extend the interface of futures-rs more if needed? In my view the separate interfaces increase the long term damage that new libraries are creating every day, and it should be higher priority to resolve it together before implementing new features in either of the two libraries (async-std and tokio).
  - Argorak 7y ago
    We don't maintain futures-rs. But for the reasons you outline above (stability), our interface is also effectively done. The choice of not using all of futures for their interface is outspoken the strategy of tokio. We have encouraged them to prefer the futures layers, but we don't see the work happening. So, to answer your question: we are not working with them, the place of collaboration is futures-rs.
- ComputerGuru 7y ago
  I have heard that using the async-std APIs (but not the reactor and executor) causes background futures to be spawned to the async-std specific executor. I’m not sure of the veracity of this claim, can you comment?
  - Argorak 7y ago
Dowwie 7y ago
Why should it be resolved ASAP? This mentality that there should be no more than one viable solution to address a need is what needs resolving. Rust would not even exist if enough people agreed with that sentiment.

bvelica 7y ago

Ok, for the uninitiated (i m still learning rust) why do we have this split? Thank you!

steveklabnik 7y ago
Which split are you talking about?
- paulddraper 7y ago
  I'm guessing async-std and tokio.

bluejekyll 7y ago

I’m always excited to see people experimenting with different things. I wonder if the author could comment on how the goals of this project might differ from those of Actix? Many people are still new to async/await; did you consider add a runtime/executor in your readme example? I didn’t see the creation of a Runtime to drive the futures, that might be a nice thing to show.

ljph 7y ago
Hi mate, The goal is to eventually have actors spread across multiple servers with automatic load balancing etc. I'm currently working on remote actors, with the goal for the API to be exactly the same whether you're talking to a local actor or a remote actor - it shouldn't matter to the user! The runtime is just Tokio's runtime, actors are just tasks awaiting on messages (and handling them) from their Receiver! Cheers!
- bluejekyll 7y ago
  Ah. Cool. What are your plans around data serialization and compatibility of different nodes during version upgrade? And thanks for the answer!
  - ljph 7y ago
    Regarding data serialization, I'm currently using serde_json, however that's just because it's easy to work with for development/testing purposes though I do love the idea of using protobufs! Node compatibility and I guess distribution overall are problems I'm extremely looking forward to tackling! :)
    - leeoniya 7y ago
      > though I do love the idea of using protobufs! or FlatBuffers!
    - samcodes 7y ago
      Not sure on rust compatibility, but have you considered Cap’n Proto? https://capnproto.org/ https://capnproto.org/

vertexclique 7y ago

Worth to mention that Bastion has been developed a lot and it has its own design(in simple terms SMP based executor) to leverage asynchronous programming (with fault-tolerant manner). It isn't dependent on any runtime. You can mix and use any runtime with it and supplies hierarchical reduction based concurrency. We proudly take Erlang's runtime model and implemented it in Rust. Moreover, we are currently working on distributed carrier protocol to make Bastion form a cluster, exchange data and recover from partial failures in distributed workloads too. Local failures are recovered and we have built-in lifecycle management. Maybe after these words you might want to take a look: https://github.com/bastion-rs/bastion https://github.com/bastion-rs/bastion You can write a fully fault-tolerant program with our macro mechanisms too: https://github.com/bastion-rs/fort https://github.com/bastion-rs/fort Here our distributed protocol repository: https://github.com/bastion-rs/artillery https://github.com/bastion-rs/artillery And our landing page: https://bastion.rs/ https://bastion.rs/

asdkhadsj 7y ago
I'm not familiar with this family of technology, so forgive the dumb question: But.. what is this? I read the landing page and browsed a couple examples and I have no clue what I would use it for. Would it be a pile of distributed workers handling jobs? Sort of like pushing a job into a job queue and having a bunch of workers consume jobs? If that's the case, what are some reasons I might choose this Bastion model over a more traditional JobQueue <-> Worker model? Thanks to any replies. I feel I should be interested, but I'm confused :)
- deleted 7y ago
  [deleted]
- vertexclique 7y ago
  As landing page states it is a runtime supplies actor-model like concurrency. If you are familiar with Erlang. Bastion is the reflection of the Erlang runtime in Rust. Far beyond an actor system implementation. It is a complete system with full asynchronous communication. "...It supplies actor-model-like concurrency with a lightweight process implementation and utilizes all of the system resources efficiently guaranteeing of at-most-once message delivery." It might be a single process, pile of workers, a bunch of http servers dispatching requests, various middleware layers connected with asynchronous boundaries. With all these built on top of crash and fault recovery. For more information what it provides please take a look to my latest presentation at Rust Berlin: https://slides.com/vertexclique/crash-course-with-bastion#/ https://slides.com/vertexclique/crash-course-with-bastion#/

staticassertion 7y ago

Nice. I tried building an actor library in rust, using proc macros. It ended up being super annoying to deal with generic actors. Maybe I'll just write a proc macro over this lib instead. * https://github.com/insanitybit/derive_aktor https://github.com/insanitybit/derive_aktor edit: Is this not on crates-io?

ljph 7y ago
https://crates.io/crates/coerce-rt https://crates.io/crates/coerce-rt :)
- staticassertion 7y ago
  Thanks.

ProfHewitt 7y ago

Actors are explained here: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566

mmastrac 7y ago

This is pretty cool. We ended up building our own version of something like this internally last year, but I could see us tossing our code in favour of this. The big advantage to writing code this way is that you just don't need to write these actors thread-safe. They will only ever handle a single message at a time. For an async system it's really fast to get something up and running.

windor 7y ago

Read through the code just now.Thanks for the small but powerful project,I have tried to make something similar, but failed. The lib is very close to what I want to do actor-based programming in Rust. It would be great if actor can send message to itself.