Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Steve Biedermann
    @hardliner66
    I'm also no akka expert. When it comes to actor systems I mostly used pony and experimented a bit with CAF.
    Lee Smith
    @leenozara

    hi @hardliner66 I've looked at your code. Removing the Box on actor_of is really nice. It'd be great to merge a PR on this. For sys.actor_of_args and removal of Props by default my immediate sense is that we should take some time to consider this. My main concern is one of mindset, that being Props being central to how it essentially is stored and used to create instances of the actor whenever it's needed. In particular for me that's true of the args case, where args are the seed components to recreate an actor and therefore need to be Copy.

    The other is that the simplicity of just a single actor_of method goes a long way - the developer doesn't need to think about what they should use. Both of these concerns become more apparent in larger projects with more complex hierarchies, where Props are generated from configs and passed around deeper to create other actors by their parents. It's one of the reasons Akka encouraged and later standardized on the use of a Props in their design: https://doc.akka.io/api/akka/current/akka/actor/ActorSystem.html. In earlier versions this wasn't the case.

    Having said that, I agree simplicity is something to strive for and I think in the case of actor_of it might be that we could have a single trait that allows operator overloading for actor_of. Not too dissimilar to the Receive trait we have. So we get to keep a single method actor_of but use different types, such as Props or an Args or a default. Maybe that's possible? We don't need to follow Akka and in many cases because it is Rust a different way is better.

    Lee Smith
    @leenozara

    Regarding 0.3.1 there's been a lot of code updates from people over the past week or so since 0.3.0 (nice!) but what we've changed has mostly been code cleanup and some minor performance improvements. Also there's some rustdocs from me that I'll merge in tomorrow. So since there's no bug fixes or new features I'm not going to publish a 0.3.1 just yet.

    Myself and a contributor has been working on the patterns crate but we're held up with a bug riker-rs/riker-patterns#5.

    We hope to get this fixed soon
    Steve Biedermann
    @hardliner66

    @leenozara Thats why I mentioned it here first. I wanted to get a sense of how everyone feels about it. My next step would have been to create an issue on github with a writup of why I think the change would be good.

    My reasoning for these changes is:

    I think for simple cases it's easier to say, "give me an Actor of type T" instead of "take something that can create an Actor of type T and create it for me".

    Thats the case I tried to optimize for, because it lowers the level of entry and I think most people who are starting to build a system using an actor model will probably start with simple stuff.

    I also think for the simple case, there should be a standard way to create props instead of "by convention". Currently I can create the props wherever I want and name the method whatever I want. Which is fine for more complex deployments, but makes the simple case more complicated than it needs to be.
    The best way for such a default is a trait which links the default methods for creation with the actor it creates which would simplify creation in the simple case and enhance the findability (i hope findability is even a word :D) of how to create props for a specific actor.

    For the complex cases, I kept the original actor_of function, but renamed it, if it is needed for more sophisticated systems or for porting software where those cases are needed. So you can still create Props from a config when needed.

    Also, if we keep the single method for actor creation, it just moves the "multiple methods for creation" into the props and removes it from the place I actually care about.

    I will prepare a pull request for the removal of box. I will also create an issue on github to evaluate if there are any more instances of box which can be removed
    Steve Biedermann
    @hardliner66
    Today I also tried to benchmark my branch against the current master and it seems my branch is currently a little bit faster. I don't know if this is because of the removal of Box or some other change. I will evaluate this and report back.
    Samir Halilčević
    @riemass
    @hardliner66 the factory function approach reminds me of how actor spawning in CAF is done. I'm up for keeping and evolving both approaches. Thanks for the PR. Removing an unneeded Box can only be good.
    Samir Halilčević
    @riemass
    We could also remove the Box around the children iterator. The ChildrenIterator exists as a type alias, and if the iterator type is ever changed, the type alias can also be changed, hence removing the need for dynamic iterator dispatching. here is how it would look like.
    Lee Smith
    @leenozara

    Hi all, Riker 0.3.1 has been published. This includes a couple of minor bug fixes, code efficiency changes and a really nice removal of Box requirement for actor factory functions:

    Props::new(Box::new(myactor::new))
    is now simply:
    Props::new(myactor::new)

    There's also been updates to the web site docs from various people.

    Thank you to all contributors:
    @hardliner66
    @dreamersdw
    @dremon
    @riemass
    @navicore
    @vvv

    [dependencies]
    riker = "0.3.1"
    Also, riker-patterns has been updated and used 0.3.1. Thanks to @vigoo for doing the heavy lifting on that.
    [dependencies]
    riker-patterns = "0.3.1"
    Lee Smith
    @leenozara
    There will soon be a series of github issues along with labels. This will make development a little easier in terms of guiding people who want to contribute. There will also be some issues around discussion, design and direction, etc. I'll post an update here once some of these issues are on github.
    Shady Khalifa
    @shekohex
    Yay :tada:
    Kelly Thomas Kline
    @kellytk
    +1
    godlin
    @godlinchong
    cargo build
    Compiling riker v0.3.1
    error[E0554]: #![feature] may not be used on the stable release channel
    --> src\lib.rs:2:1
    |
    2 | #![feature(async_await)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^
    What should I do about it?
    Steve Biedermann
    @hardliner66
    You have to use the nightly toolchain.
    If you installed rust via rustup, you can override your toolchain for your project with:
    rustup override set nightly
    Kelly Thomas Kline
    @kellytk
    Will Riker move to stable once async/await lands? (est. 1.38)
    Steve Biedermann
    @hardliner66
    According to riker-rs/riker#59 it should be possible to switch to stable once async/await lands.
    Kelly Thomas Kline
    @kellytk
    Thanks
    godlin
    @godlinchong
    Thanks
    Samir Halilčević
    @riemass
    Hello folks. I've looked into the current implementation of the riker timer and I've noted two complains on my side: every frequency_millis the vector of jobs gets split into two, meaning two dynamic allocations, and for every n jobs, SystemTime::now() inside partition, which jumps into kernel to get the current time.
    I have a better implementation that I've prototyped to execute arbitrary lambdas at a given timepoint, and I would be more than glad to integrate it into riker if the community is interested.
    If anyone wants to take a look here: https://github.com/riemass/timer/blob/master/src/main.rs
    rustrust
    @rustrust
    is there a riker based web server?
    Kelly Thomas Kline
    @kellytk
    +1
    Kelly Thomas Kline
    @kellytk
    @leenozara ^
    We very much need an alternative to actix web, which would be something like a project demonstrating using Hyper with Riker
    Kelly Thomas Kline
    @kellytk
    If that project was then also paired with tokio-postgres in a second project, demonstrating a full request/response cycle from WebSocket (wss) connection, protocol message, passed into Riker, and fulfilled using contrived data via a query to a PG DB, that would be very compelling.
    Lee Smith
    @leenozara
    Hi @riemass @kellytk sorry for the delayed reply. I'm looking at your comments now
    @riemass I like your prototype. There's also this issue: riker-rs/riker#42
    use of SystemTime is not the best fit since it can be affected by changes to system clock, including daylight saving adjustments
    Lee Smith
    @leenozara
    @kellytk I agree and this is something I'd really like to get done. I did have an example using warp crate pre 0.3 but that wasn't great since the differences between futures version.
    Kelly Thomas Kline
    @kellytk
    Hyper perhaps then?
    Lee Smith
    @leenozara
    Http seems to be one of those components that depends on the development team's personal preference, especially code style, i.e. functional vs object vs imperative. I think having clear examples with easy to use riker components that can use http, whether it is hyper, rocket, iron, warp, etc would be a good approach.
    for example, we could have the same example project that is implemented using different http crates, as examples
    is this what you were thinking also?
    Kelly Thomas Kline
    @kellytk
    Yes and no. I wouldn't recommend a monolithic solution that bundles Riker with a web server from the Rust ecosystem, for the reason you gave among others, but I also wasn't recommending that an example be created of Riker working with all popular web servers from the Rust ecosystem due to the workload. That said, I think your idea is probably the best. I'd execute it by demonstrating using one, perhaps the most correct/feature complete/performant web server, (Hyper or otherwise) and then either adding others or soliciting submissions from the userbases of the other web servers
    To lay the groundwork for a common implementation, we'd probably want to begin by specifying precisely what the demo would do, secondly evaluate which web server should be the first to use Riker with, then implement it
    Support for additional web servers should follow that same specification so people evaluating their options for adding web server support to Riker could compare the implementations on an apples-to-apples basis
    A second specification could be added for the web server + Riker + DB query example with n implementations as well.
    Samir Halilčević
    @riemass
    @leenozara I'll prepare something. Ill handle riker-rs/riker#39 and riker-rs/riker#42 together with the new timer. Hope that it will be ready till the end of the weekend.
    Songtronix
    @Songtronix
    I can't customize the default logger. Though like the documentation says I use {date:.0}to remove it.
    Samir Halilčević
    @riemass
    We had an issue with runtime-fmt not building with the latest nightly and the maintainer did not respond, so we had to disable that feature as a temporary solution. Sorry for your trouble, hope we fix it soon. Here is the code confirming it.
    Songtronix
    @Songtronix
    Oh well. Good to know.
    Kelly Thomas Kline
    @kellytk
    Thoughts on using https://github.com/async-rs/async-std in Riker?
    Kelly Thomas Kline
    @kellytk
    riker-rs/riker#69 brings up a distributed actor system scenario I mentioned a couple of weeks ago where part of the system is server-based Riker actors and another part is WASM/client-based Riker actors. I think it's worth thinking about
    Shady Khalifa
    @shekohex
    Hi, it's me again :smiley: , I'm willing to build MQTT broker in rust, and the actor model seems the best fit in this example, and I'm willing to use riker
    so any suggestion for examples to start with?