Rust Actor Library: First Assorted Thoughts
dbeck.github.io
dbeck.github.io
"This actor library runs tasks with the help of fixed number of threads".
This is a M:N user-space scheduler for threads, a re-implementation of what Go provides as part of the language but with 10x the complexity (things that Go doesn't expose: Scheduler, a Task, a SchedulingRule, a Sink, a Filter, a YSPlit and what not).
I'm not a CS historian but this is what Alan Kay complains about when he talks about the pop culture of computer science.
Actor model (https://en.wikipedia.org/wiki/Actor_model) is a somewhat deep idea about structuring systems as independent entities that communicate via sending messages.
A thread is not that. The similarity is superficial.
To the extent that it's about threads that can communicate over channels, it's closer to CSP (https://en.wikipedia.org/wiki/Communicating_sequential_proce...) but as the page says "the two models (CSP and actors) make some fundamentally different choices with regard to the primitives they provide".
It's telling that the only time an actual actor is mentioned is in the name of the library. The actual code talks about tasks, channels, schedulers.
Something might be called an actor if it can:
1) Create other actors at runtime 2) Send and receive messages to/from other actors asynchronously 3) Can do something in response to messages and then optionally change this behavior in anticipation of the next message.
(Meaning: if you have to predefine all "actors" at compile time, this is not actor model. If you have to predefine "exchange points" AKA channels to communicate between two actors synchronously, this is not actor model. If you can't change your behavior at runtime, this is not actor model.)
Actors are very dynamic entities operating in a wild west environment without any guarantees (about delivery, or message ordering, etc -- just like the IP stack). Messages are sent in "fire and forget" fashion. The power of actor model is that it can be useful even in such an environment.
The author is clearly interested in developing a derivative of Erlang/OTP that works for the author. Erlang is often described as an implementation of the actor model.
There are also differences to the Erlang/OTP too. This library uses typed messages and taking advantage of the compiler to do type checking. I found it is easier to create this library if 1) the number of input and output channels are fixed 2) the topology of who sends to whom is fixed when the tasks are passed to the scheduler.
I was just about to start writing the equivalent of rotor as a thin plugin you can tack on to a mio event loop alongside whatever but with this I think I can get away with simply starting an event loop ahead of time and passing events back into my web app. It'll be interesting to play with it.
The current state of affairs is somewhat up in the air because Alex Crichton (futures) and Carl Lerche (mio) are working on the Tokio project [0][1], which is likely to become the most favored way to do things on top of mio.
[0] https://github.com/tokio-rs/ [1] https://medium.com/@carllerche/announcing-tokio-df6bb4ddb34
It's still under construction!
Every day something new breaks, haha. Whether it's tokio-middleware with the "what was I thinking?" patch:
https://github.com/tokio-rs/tokio-middleware/commit/78210757...
(seriously, click that link it's funny)
...or today's fun:
https://github.com/tokio-rs/tokio-minihttp/issues/12
The good news though is that it is obviously being worked on--heavily. The Rust ecosystem is so new that it feels a bit like we're in the Wild West. Someone comes up with a decent way to do something and then after a bit of ecosystem evolution we're back to the drawing board since, "there's a better way."
This is all very good because it means that the Rust ecosystem is evolving rapidly. It also means that developers are productive enough in the language that entire frameworks can be re-written from scratch in a reasonably short amount of time. I think it's a good demonstration of how effective the language is overall at its goal of improving productivity (as far as systems programming languages go).
This is pretty normal for an ecosystem at Rust's stage of development. Ecosystem development is always something of a monkeys-on-typewriters effect and if you continuously have major disruptions in the language, you wind up with Javascript Fatigue.
What I'm particularly impressed with in Rust is the core team's leadership. I'm looking forward to Tokio because I think it's likely to have Rails-like dominance over the ecosystem. This is exciting because it gets us monkeys all pointed in the same direction instead of writing another postgresql client because existing ones don't support the current flavor of event loop that I'm using. Getting to the point where we can snap a bunch of pieces together and have a network service is huge for office advocacy. I think it was a key factor in Ruby's wins over the more established Python web community when observing from the Python side.
I'm also pleased that the Rust core team is focused on my pet areas of improvement: editor support, impl Trait, and async network services.
With tokio I could unify my code base and make the code simpler and easier to follow.
There are also some "Are we X yet?" sites that cover ecosystem maturity for specific topics. Here are all the Rust-specific sites linked from Mozilla's page (https://wiki.mozilla.org/Areweyet):
Web Programming - http://www.arewewebyet.org/
Concurrency - http://areweconcurrentyet.com/
IDE/Editor Support - https://areweideyet.com/
Machine Learning - http://www.arewelearningyet.com/
Game Development - http://arewegameyet.com/