4 ms·

Rust Actor Library: First Assorted Thoughts

95 points by dbeck74 10y ago

riskable 10y ago
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 10y ago
  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?
  - solipsism 10y ago
    Discovery and curation of crates is one of the near-term goals of the Rust team. At least they said as much at RustConf.
  - xorxornop 10y ago
    Until better solution is introduced by Rust core team, the Awesome Rust initiative is probably next best thing
    - dimfeld 10y ago
      Agreed, Awesome Rust is a great resource. Here's the link: https://github.com/kud1ing/awesome-rust https://github.com/kud1ing/awesome-rust 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 https://wiki.mozilla.org/Areweyet): Web Programming - http://www.arewewebyet.org/ http://www.arewewebyet.org/ Concurrency - http://areweconcurrentyet.com/ http://areweconcurrentyet.com/ IDE/Editor Support - https://areweideyet.com/ https://areweideyet.com/ Machine Learning - http://www.arewelearningyet.com/ http://www.arewelearningyet.com/ Game Development - http://arewegameyet.com/ http://arewegameyet.com/
  - grayrest 10y ago
    > 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 10y ago
      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/7821075760fa73f2762bd0e1af869bc5ee21a053 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 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).
      - pimeys 10y ago
        I'm one of the persons waiting for a stable tokio so badly. I have many use cases for this in my Rust projects that are either currently doing async io so-so or doing stuff like firing http requests in sync using the tools available. The situation in hyper land is not very cool at the moment, master being async but requiring you to write the callbacks, stable using too old openssl and the tokio branch not compiling. With tokio I could unify my code base and make the code simpler and easier to follow.
- dbeck74 10y ago
  Thank you. All feedbacks are very welcome.
setori88 10y ago
How much different is this from https://github.com/fractalide/fractalide/tree/master/support/rustfbp https://github.com/fractalide/fractalide/tree/master/support...?
- solidsnack9000 10y ago
  Fractaclide provides an IDL, a build system and an approach to distribution.
kjksf 10y ago
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_processes 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.
- atemerev 10y ago
  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 10y ago
    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

95 points by dbeck74 10y ago

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 10y ago
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?
- solipsism 10y ago
  Discovery and curation of crates is one of the near-term goals of the Rust team. At least they said as much at RustConf.
- xorxornop 10y ago
  Until better solution is introduced by Rust core team, the Awesome Rust initiative is probably next best thing
  - dimfeld 10y ago
    Agreed, Awesome Rust is a great resource. Here's the link: https://github.com/kud1ing/awesome-rust https://github.com/kud1ing/awesome-rust 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 https://wiki.mozilla.org/Areweyet): Web Programming - http://www.arewewebyet.org/ http://www.arewewebyet.org/ Concurrency - http://areweconcurrentyet.com/ http://areweconcurrentyet.com/ IDE/Editor Support - https://areweideyet.com/ https://areweideyet.com/ Machine Learning - http://www.arewelearningyet.com/ http://www.arewelearningyet.com/ Game Development - http://arewegameyet.com/ http://arewegameyet.com/
- grayrest 10y ago
  > 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 10y ago
    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/7821075760fa73f2762bd0e1af869bc5ee21a053 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 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).
    - pimeys 10y ago
      I'm one of the persons waiting for a stable tokio so badly. I have many use cases for this in my Rust projects that are either currently doing async io so-so or doing stuff like firing http requests in sync using the tools available. The situation in hyper land is not very cool at the moment, master being async but requiring you to write the callbacks, stable using too old openssl and the tokio branch not compiling. With tokio I could unify my code base and make the code simpler and easier to follow.
dbeck74 10y ago
Thank you. All feedbacks are very welcome.

setori88 10y ago

How much different is this from https://github.com/fractalide/fractalide/tree/master/support/rustfbp https://github.com/fractalide/fractalide/tree/master/support...?

solidsnack9000 10y ago
Fractaclide provides an IDL, a build system and an approach to distribution.

kjksf 10y ago

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

atemerev 10y ago
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 10y ago
  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