[p33p]

I don't particularly care about high throughput streaming architecture. The actor model as a concept, its concurrency, and how that models the business domain is more along the lines of what I'm interested in. Same as what intrigues me about Elixir as well, but I need hundreds of thousands of actors that can react to events that require numerical computing.

[lihaoyi]

If you're interested in Actors, the book has a chapter `Chapter 16: Message-based Parallelism with Actors` that does an introduction to them, and they are used "in anger" in `Chapter 18: Building a Real-time File Synchronizer`. I've worked hard to make this the best introduction to real-world use cases of Actors I've seen anywhere on the internet.

For simplicity, it uses a tiny Actor library instead of a big framework like Akka, but all the concepts and techniques should be transferrable to any Actor-based application

[njacobs5074]

Actors, in of themselves, are pretty lightweight. The bigger challenge is figuring out how many threads you want to configure to back them.

Also, consider that while message passing as an architecture can lend itself to well-structured applications, it's not a panacea against issues like deadlock & livelock.

It also sounds like you may need some kind of distributed fabric for that kind of system and again, while Akka provides an elegant toolset, you still have to contend with network resiliency issues.

TBH, I have found biggest challenge in constructing these architectures is coordinating their completion or shutdown. You can up with thread leaks that will only show up through extensive testing or experience.

[bozoUser]

If there`s state associated with Akka actors, to shut them down in a proper manner and not lose state you have to use Akka persistence which just means doubling down on Akka ecosystem.

[dionian]

I would rather use Monix Task than Akka for this if i could get away with it. ZIO looks really cool too. Worth a look since these things are more typeful

[bozoUser]

why not use Futures ?

[lihaoyi]

Futures and Actors are complementary tools, and neither is really a substitute for the other. `Chapter 16: Message-based Parallelism with Actors` has a good discussion of when you would use each one, and some of the exercises involve using them together