
Rust Actor Library: First Assorted Thoughts - dbeck74
http://dbeck.github.io/Rust-Actor-Library-First-assorted-thoughts/
======
kjksf
Why does it call itself an "actor" library?

"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](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...](https://en.wikipedia.org/wiki/Communicating_sequential_processes))
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.

~~~
atemerev
Yes, exactly.

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.

~~~
dbeck74
Thank you for the feedback. This helps me a lot in deciding which area of this
library needs more explanations. In a followup post I'll show 1) how to create
actors run-time, 2) send and receive messages 3) respond to messages. 4) that
the messages are async

------
riskable
This looks awesome. It's exactly the sort of thing I've been looking for as a
means to bridge the gap between web libraries that want to own the
mio::poll::poll() loop (providing no access to register listeners of your own)
and rolling literally everything myself. It's a BIG gap!

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.

~~~
jzelinskie
I just started diving more into Rust recently and have been trying to
understand the current state of the ecosystem. I've been looking at a bunch of
the libraries that expand upon mio, but this is the first time I've heard of
`rotor`. Besides searching crates.io and judging based on the download
numbers, is there better way to discover important crates?

~~~
grayrest
> I've been looking at a bunch of the libraries that expand upon mio, but this
> is the first time I've heard of `rotor`.

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/](https://github.com/tokio-rs/) [1]
[https://medium.com/@carllerche/announcing-tokio-
df6bb4ddb34](https://medium.com/@carllerche/announcing-tokio-df6bb4ddb34)

~~~
riskable
I just want to add that I _really_ like where Tokio is going. The architecture
seems well-thought-out and exactly the sort of thing I'm looking for. There's
only one problem though...

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...](https://github.com/tokio-rs/tokio-
middleware/commit/7821075760fa73f2762bd0e1af869bc5ee21a053)

(seriously, click that link it's funny)

...or today's fun:

[https://github.com/tokio-rs/tokio-
minihttp/issues/12](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).

~~~
grayrest
> The Rust ecosystem is so new that it feels a bit like we're in the Wild
> West.

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.

------
setori88
How much different is this from
[https://github.com/fractalide/fractalide/tree/master/support...](https://github.com/fractalide/fractalide/tree/master/support/rustfbp)?

~~~
solidsnack9000
Fractaclide provides an IDL, a build system and an approach to distribution.

