
Show HN: Coerce – Actor runtime for Rust using async/await and tokio channels - ljph
https://github.com/LeonHartley/Coerce-rs/
======
bluejekyll
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
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
Ah. Cool. What are your plans around data serialization and compatibility of
different nodes during version upgrade?

And thanks for the answer!

~~~
ljph
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! :)

~~~
samcodes
Not sure on rust compatibility, but have you considered Cap’n Proto?
[https://capnproto.org/](https://capnproto.org/)

~~~
aseipp
Cap'n Proto has good a good Rust library, but it's overall language support
versus alternative formats is somewhat lacking, unfortunately.

That said, Cap'n Proto has a substantially better design (both in theory and
implementation) than any of the alternatives IMO, so it's worth using anyway
if your language supports it well. And especially so if you're using it
"internally", so other language clients aren't as big of a deal.

------
vertexclique
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
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 :)

~~~
vertexclique
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#/)

------
ProfHewitt
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
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.

------
staticassertion
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
[https://crates.io/crates/coerce-rt](https://crates.io/crates/coerce-rt) :)

~~~
staticassertion
Thanks.

------
windor
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.

------
xiphias2
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?

~~~
Argorak
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
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
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.

------
artfulhippo
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
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.

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

~~~
steveklabnik
Which split are you talking about?

~~~
paulddraper
I'm guessing async-std and tokio.

