71–80 of 88 posts
From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…
Earlier quoted context omitted.
I've played with this a bit, professionally and personally (Scala/Akka specifically). The way it makes you think about your model and the boundaries it introduces seem good. I really love the way it forces you to model the communication between parts of your code as a data structure - it feels like a much less costly version of the "everything as a micro-service" dream. Scala seems like the ideal language for it - yo…
> Akka was still struggling with type loss in the system the last time I used it, which really felt like a pain, and where I feel it adds the boundary that makes it harder to understand. I don't know if this is what you are referring to, but: I don't understand the mix of Akka actors and Scala. Scala is a statically typed language -- in fact, that's the whole point of it -- and using Akka actors feels a bit like prog…
The typed actors stuff does exist, but it's experimental, and the last time I checked they had just thrown away the old version and were working on a new implementation. It seems like it would be better, but it's clearly not done yet.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way proces…
Earlier quoted context omitted.
>It's worth mentioning that this isn't the only way to do distributed programming. Its not the only way, but it is one of the oldest that is still in production. If you take a train anywhere in the Western world, your life is being protected by best x-of-x systems based around the actor model. Just sayin' ..
I don't think that's true. Ericsson used it at one point. What makes you think every single train in the "Western world" uses it as well?
Siemens, Thales, Ericsson, Samsung - all have shipped SIL-4 systems based around the Actor/Voting model in the past, because it is an industrial standard. These systems are still out there, in some cases 20+ years later, in track-side systems as well as operations.
Earlier quoted context omitted.
I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way proces…
Why it is necessary to discard messages? Isn't it a sign of bad design when resources have to be spend to create and pass a message that is ultimately discarded?
For instance if you have a process that gets requests and writes stuff to DB, while processing a request you can send a message to the DB, then use a selective receive to match on the response from the DB while ignoring all other messages (you’ll deal with them later i.e. when you fetch the next request to process).
A while into the project, my team and I were responsible for delivering a subcomponent within the system. We did so with extreme prejudice to only using actors at the very edges and entry points where a bit of asynchronicity was required. But everything within the service boundary was just plain old Java. This was the easiest to understand and maintain part of the system, as attested by another team who we handed over the entire codebase to. Guess which part had the least bugs? Most extensible?
I don't know if akka has improved since then, but the debug workflow was such a departure from the normal way of doing things on the JVM it was enough to put me off and then steer clear of it in general. There are definitely other patterns and libraries I would reach for first.
Earlier quoted context omitted.
I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way proces…
Why it is necessary to discard messages? Isn't it a sign of bad design when resources have to be spend to create and pass a message that is ultimately discarded?
I have coded one significantly large system using Akka. I think conceptually, actors are quite simple and powerful. But in practice with Akka, I hated the fact that I couldn't just set a breakpoint and just follow a message all the way through the system via multiple F7's. Every time I got to a "send" call, I would need to find out which of the other 200 actors in the code actually dealt with that message, set anothe…
I have coded one significantly large system using Akka. I think conceptually, actors are quite simple and powerful. But in practice with Akka, I hated the fact that I couldn't just set a breakpoint and just follow a message all the way through the system via multiple F7's. Every time I got to a "send" call, I would need to find out which of the other 200 actors in the code actually dealt with that message, set anothe…
I have come to realize that breakpoint style debugging should be avoided. Atleast for people working on Services. Prefer logging, or other variants like Event History, State Change history, etc.