Hi all,
I would like to announce a new application framework for building concurrent, self-healing systems. Riker attempts to make this as easy as possible by providing core services out of the box. At its core Riker is an actor runtime partially inspired by Akka.
Rust really makes it possible to make an actor framework for solving modern problems such as Microservices, Drones, IoT and Robotics. Rust's safety combined with actor resilience ends up being a good solution for solving modern engineering problems.
Riker provides:
- An Actor based execution runtime
- Actor supervision to isolate and recover from failures
- A modular system
- A Dispatcher backed by futures::execution::ThreadPool by default
- Publish/Subscribe messaging via actor channels
- Message scheduling
- Out-of-the-box, configurable, non-blocking logging
- Persistent actors using Event Sourcing
- Command Query Responsiblily Separation (CQRS)
- Run futures alongside actors
I should apologize for the current state of documentation. Over the coming weeks there will be a greater emphasis on building out the documentation and proving more examples. I will also be creating examples projects that demonstrate Riker's capabilities. Please do bear with me while the all of the supporting elements of an open source project are being improved.
Note that currently Riker uses the futures-preview crate. This will be changed to 0.3 of the futures once that is available.
A non-crates version Riker has been used to develop several real world applications which hopefully can be documented as case studies in the near future.
I hope Riker helps some of you here in your future Rust projects. I'm happy to assist where I can.
Thank you.
Website: http://riker.rs
GitHub: https://github.com/riker-rs
Gitter: /riker-rs
8 Likes
This looks extremely cool, and I'm excited to see the actor model growing in popularity in the Rust world!
What are the main differences between this and something like Actix?
2 Likes
As there's a supervisor I had hoped it would be distributed across multiple processes / machines, but from a quick glance at the code it seems to be single process for now? I know actix ( https://github.com/actix/actix-remote ) is working towards this goal.
Competition is a good thing 
2 Likes
I'm only vaguely familiar with Actix so I'll leave the community to do an unbiased comparison at some point.
As an application framework Riker attempts to provide a mix of solutions to common problems. This includes event sourcing for persistent actors, nio logging, pub/sub channels for choreography. There's also a strong emphasis on actor hierarchy to model applications to not leak errors.
Thanks for your comment! Let me know if you ever need help using Riker.
3 Likes
Clustering is the current theme on the roadmap and is already a few months in development. However I didn't want to wait to release Riker. The project is already too large for a couple of people to maintain and my hope is that other folks can contribute.
On the git repo at the bottom of the page I've outlined a simple roadmap:
The next major theme on the project roadmap is clustering and location transparency:
- Remote actors
- Support for TCP and UDP
- Clustering (using vector clocks)
- Distributed data (CRDTs)
Remote actors without clustering aren't so useful since, as you mentioned, supervision needs to extend across multiple actor systems. This is particularly important in persistent actors since only one instance should exist in the cluster.
Even though there's no clustering currently I've had a lot of success load balancing instances. As part of a supervision strategy you can have an application remove itself from the load balancer if it fails. It can also add itself when it's healthy. This approach can often give you better results than the overhead of a cluster layer, and you only ever need to think about the application in a local context.
I hope you give Riker a shot. Thanks for your comment.
2 Likes
Excellent. Am totally watching this space... 
1 Like
I understand why you’d want to leave a comparison up to the community, even if you were intimately familiar with actix. But, actix has gotten substantial “press”, and backs another framework that’s gotten it: actix-web. As it stands, if I were looking for an actor framework right now, I’d very likely go with actix and only look for alternatives if there was something about it that I didn’t like or something else compelling came along.
As such, for everyone’s benefit, I think it’d be great if you could compare and contrast Riker and actix, at least in the short term. For example, I can’t tell if you would’ve developed Riker if you knew actix better (or it was available when you started).
I think competition is great and kudos for developing it, but on the flip side, “needless” fragmentation via multiple implementations of a similar thing has its downsides unless it’s apparent why multiple exist.
Just my $.02
3 Likes