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.
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.
@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.
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"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"
rustup override set nightly
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.
SystemTime is not the best fit since it can be affected by changes to system clock, including daylight saving adjustments
n implementations as well.
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.