Create a Rust actor library with high-level patterns, recovery, networking, sandboxing

[brson]

Rust has a lot of powerful concurrency tools, but they aren't packaged up into a high-level, consistent interface.

Things that would be great in an actor library:

• High-level help with implementing actor patterns, nice interface, minimal boilerplate
• Cross-process actors with sandboxing. Sandboxing is very important to Servo, which has some initial sandboxing libraries.
• Network-based messaging and actors
• Reliable failure and recovery schemes. Rust has linked task failure, but no higher-level constructs to help users make use of it for creating reliable systems ala Erlang OTP.

Take inspiration from Scala, Akka and Erlang.

This probably isn't suitable for the main repo, but would be very useful for projects like Servo.

[ndemonner]

+1. Providing modular functionality à la OTP for building reliable, easily-distributed apps in Rust would be amazing. First questions: how lightweight are tasks compared to, say, Erlang processes? Are they analogous?

[brson]

They are intended to be lightweight enough to not require much thought about how lightweight they are, but currently there is a fair bit of overhead.

Most of the overhead is in allocation and scheduler interaction. Rust tasks (in C++) are heap allocated and contain quite a few and I believe the total size of a task structure is in the high hundreds of bytes, then there are also Rust-side task state stored in task-local storage.

The biggest allocation cost for a task is the stack, and regardless of the crazy optimizations we do we will always have to allocate a new stack segment for each new task. Right now stack segments have a large, wasteful 'red zone' where Rust code does not run but various bits of other code do. The size of the initial stack segment on Linux is 2KB and on other platforms is a wasteful 20KB. There is a lot of opportunity for optimization here and I believe we should be able to get into the 1KB range (on Linux at least).

There are plans to lazily initialize tasks in the hopes that short-lived tasks can basically execute using their parents' resources, which, at the limit, will mean new tasks just need to allocate a stack segment to run on.

I think we will get there eventually.

Also during the 0.4 development cycle there was a huge task spawning perf regression for as yet unknown reasons, but presumably that can be recovered.

[donbrowne]

I'd be interested in working on this, where should I go from here? (I posted on the student section too, apologies for double post)

[brson]

@donbrowne Hi! I'm glad you are interested in working on this.

You should be aware that we are in the early stages of completely rewriting the Rust scheduler (#4419) so there is going to be a great deal of churn in this area this year. I'm also pretty intent on rewriting how linked task failure in Rust works to make it simpler. I want the built-in failure propagation to be more like Akka's task tree and less like Erlang's task groups (though I'm not intimately familiar with either). In generally I want the Rust core library to have the minimal capabilities necessary for external libraries to build on and experiment with different policies.

If you decide to go down this route it's going to be an adventure and it there could be a fair amount of yak shaving as Rust evolves.

As to actor libraries, I'm not well acquainted with existing ones, so it's going to be important to have experience with existing systems and to have an opinion about what they do right and wrong. From my perspective this project is about identifying traditional actor use cases and ensuring that Rust can support them. I would start with a survey of existing systems, identifying what the requirements are, and figuring out how Rust's features can be adapted and augmented to fulfill them. One major concern I have is that Rust is statically typed and the actor system's I'm aware of (Erlang, Scala, Akka) have dynamically typed messages. How can the actor model be adapted to static typing (fwiw Rust originally intended to have limited dynamic typing but so far there hasn't been a pressing need)?

I'd also strongly recommend that as you solidify your plans that you share them on the mailing list. You may find people there who have better ideas on this topic than I. In the end this is a very open-ended project, particularly since it is an external library, so it will largely be up to you to set the goals and direction.

[brson]

One other persistent concern I've had about Rust actors is that, in all actor systems I'm aware of, one can select from just a subset of all possible messages in the mailbox. If, in your current state, you aren't interested in receiving the Quit message, you can make the receive function ignore it and drop it back into the mail queue until you do want it. In Scala's library this is implemented with their first-class partial functions - which Rust doesn't have. I think this behavior is more or less what the original actor papers described as the become operation, where an actor takes on a different persona temporarily, but it's been a while since I read it.

[ksev]

I would like to propose some extra reading material.

Akka typed actors: http://doc.akka.io/docs/akka/2.1.0/scala/typed-actors.html
I have never used them (and i use akka quite a bit in my day job) and as apparent by the documentation they are not the common case.

Cloud haskell: http://www.haskell.org/haskellwiki/Cloud_Haskell and http://haskell-distributed.github.io/
They have been pretty good at documenting how and why they built cloud haskell.
It is heavily inspired by erlang but fixes some of the sematic problems of erlang as described here: http://dl.acm.org/citation.cfm?id=1863514 cloud haskell support both typed and untyped channels.

[mictadlo]

Implementation of Erlang/OTP node in Go ( https://github.com/goerlang/node ) another project which use it is https://github.com/goerlang/eclus . Here are even parts from erlang written in GO ( https://github.com/goerlang ). Could maybe be converted to Rust.

[bblum]

triage visit; nothing to contribute

[MaikKlein]

is anyone working on this?

[huonw]

triage: no progress that I know of.

[mictadlo]

Cloud Haskell ( http://www.haskell.org/haskellwiki/Cloud_Haskell ) tries to implement OTP:
"There is also an effort ( https://github.com/haskell-distributed/distributed-process-platform ) underway to develop an OTP-like platform for Cloud Haskell. In addition to providing many of the features that OTP offers (e.g., generic managed processes, supervision trees, etc) this layer provides an implementation of the task layer described in the original paper and implemented in the remote package. There is much to do her also, and any help would be much appreciated!"

[splix]

There are two project that have a basic stuff for Rust actors:

• https://github.com/MaikKlein/RustActors
• https://github.com/FlaPer87/rust-actors

[psahabu]

Hello, I'm an undergraduate at the University of Washington and I am planning on creating an Actor library for Rust as part of my senior thesis. A professor and a grad student have already signed on to advise me, and my work will begin in earnest next quarter. I have been using Akka to get a better understanding of actor libraries, and it'll take me some time to familiarize myself with Rust itself, but I hope that my work will eventually be useful to the community at large.

[brendanzab]

I have a PR (#10818) open for adding a gen_server kind of thing to libextra. Not sure if it should be a standalone lib though. I'm also going to try to implement gen_fsm and gen_event, but I'm not sure if it will be possible with rust's concurrency primitives or type system.

I've since made some updates to my PR, but haven't pushed them yet. Here's a gist though.

[brendanzab]

I would also highly recommend John Reppy's Concurrent Programming in ML if you'd like to get up to speed with Rust's concurrency primitives (Rust's primitives are much closer to CML than Erlang).

[pnkfelix]

assigning P-low.

[sinistersnare]

@sahabp What is the status of your library RustActors (Cage)? It looks like your paper is done.

[psahabu]

@sinistersnare Cage more showed that Actors could be created on top of tasks with a nice interface, but it's not extremely durable and it doesn't have any of the great features listed above (cross-process, networking, easy failure and recovery). It also stuck with the Akka hierarchy model of Actors, which in retrospect was a bad design decision.

I'd totally be down to be work on a full-featured library, if people are interested.

[itdaniher]

I'm absolutely interested in working on a full-featured library. I've been actively experimenting with a DSL for process graph description and would love to be able to draw on high level resources like those mentioned above.

[photex]

Add me to the interested parties list. Akka and Akka-IO have been enormously useful for some projects at work and I'd very much like to have something similar in Rust. An example would be an application that implemented serial and udp based protocols communicating with endpoints concurrently. A Rust version of this would be the bees knees I tell ya!

There is a C++ actor-framework that might be of some interest: actor-framework

[neich]

Count me in. I've just started to experiment how would be to port akka to rust, but the language is too different.

@sahabp just curious, why the Akka hierarchy model of Actors was a bad design decision ?

[iskandr]

I've just started experimenting with rust but I would also be interested in working on an actor library.

[target-san]

@neich Maybe because of the hierarchy itself.
I'm personally interested to participate in such effort. Though the problem is, we need some central point to gather. It would be pointless for each one of us to develop his own pocket Akka/Erlang killer.

[bandrei]

I'm considering joining in too. More for the rust learning experience. Let me know if you guys intend to start this.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#613