There is something thats not clear to me. when using persistent typed actors, there is a trait EventSource which should not be extended wich is good for functional style actors .....all the samples use a singleton object ... what if i wanted to map each item in a warehouse to a persistent actor, then the problem is functional style forces me to use singleton objects ... so i cant find a way to use persistente actors in the scenario. ....... any clue would be appreciated.
@@rockthejvm I would like a video showing the different types of ExecutionContext (scala.concurrent.ExecutionContext.Implicits.global) and when to use.
Great Video. Quick question - For some if I wanted to retry the message, How can we achieve it without waiting for the next message. i.e. If you just send "emotionalActorSystem ! EatChocolate" I wanted to execute it 2 times based on some condition without waiting for the next message. Can we do context.self ! EatChocolate
akka-typed seems unnecessary complicated than akka-actor, and with constant creation of new object of behavior for every incoming message, it seems like a performance penalty. Why would we use akka-typed in the first place?
Boilerplate has nothing to do with performance. This code is what aesthetics sacrifice for type safety, which was one of the major flaws of "old" actors.
I love your tutorials! They are in perfect form.
By the way, I can't wait to watch more of "Scala 3" series.
Will do more!
Great intro to Behaviors with Akka Typed. I recommend doing a video with an example of an Akka Typed timer/scheduler. Cheers =)
Will do - lots more incoming!
Thanks that was a great introduction, I have a job interview where I have to create a simple service using actors.
Thank you Daniel, really nice explained
Glad it helped!
myHappiness += 100
you an crate the actor using the actor system or by extending the actor trait
Maybe it is just terminology, but for me both actors are stateful. They have internal state. One is mutable and another one is not.
Sure - as long as you got the idea, that's all I wanted
@@rockthejvm yes, as always, this video was very helpful. Thank you!
There is something thats not clear to me. when using persistent typed actors, there is a trait EventSource which should not be extended wich is good for functional style actors .....all the samples use a singleton object ... what if i wanted to map each item in a warehouse to a persistent actor, then the problem is functional style forces me to use singleton objects ... so i cant find a way to use persistente actors in the scenario. ....... any clue would be appreciated.
Having each item with its own persistent actor might be too granular.
@@rockthejvm what should be the ideal case ?
@@christianvalverde1247 it depends on what items you hold and how you access them, but the "DAO" should be a persistent actor
Great !! very useful for PR :)
Glad it helps!
@@rockthejvm I would like a video showing the different types of ExecutionContext (scala.concurrent.ExecutionContext.Implicits.global) and when to use.
Great Video.
Quick question - For some if I wanted to retry the message, How can we achieve it without waiting for the next message. i.e. If you just send "emotionalActorSystem ! EatChocolate" I wanted to execute it 2 times based on some condition without waiting for the next message.
Can we do context.self ! EatChocolate
You can simply send the message twice, i.e. call `emotionalActorSystem ! EatChocolate` two times?
akka-typed seems unnecessary complicated than akka-actor, and with constant creation of new object of behavior for every incoming message, it seems like a performance penalty. Why would we use akka-typed in the first place?
Boilerplate has nothing to do with performance. This code is what aesthetics sacrifice for type safety, which was one of the major flaws of "old" actors.