In the previous article we’ve implemented a standalone guessing game, but actors are built for much more complex problems such as concurrent communication over a network. A turn-based multiplayer game such as a card or tile game is the perfect example for that use case, and that’s what we’d like to achieve eventually. But first, we need to figure out how to allow actors to communicate with each other over a networking layer, and possibly with a high enough level of abstraction so that we can model our business rules without having to think about any low-level stuff.

Thankfully, Akka does this abstraction so well that the whole process is almost entirely transparent. Let’s see how!

Now that the basics of the actor model is out of the way (thanks to the previous article), it’s time to make something with it! We’ll begin by creating an Akka project from scratch, and then move on to implementing a number guessing game based on actors, which will give us an easy start in modeling actor-based systems.

The rule of the game is quite simple; it’ll pick a random integer between 1 and 100, and user will try to guess it. Each time the user provides a guess, the game with reply with a message that tells the player whether or not they matched. All interaction will be through the console, so no unnecessary complication there.

Note: I won’t go into any details about the model nor Akka’s implementation of it, so if you’re ever in need of assistance, feel free to use the previous article as a reference.

By the time I took the Principles of Reactive Programming course on Coursera last spring, I was already a fan of Scala and concurrent programming, so it was no big surprise that I fell in love with the actor model the moment I heard about it during the course. I’ve been wanting to write about it ever since, but have only recently had the time to actually do it.

Let this be the first in a series of articles where I explore the actor model; what it is, how it works, where it can help, and how some of its use-cases may be implemented. I’ll first describe what the actor model is and how Akka implements it, then move on to simple examples like hot-or-cold games, and finally end up in client/server applications such as multiplayer card or tile games.

Disclaimer: This post assumes that you’re at least somewhat familiar with Scala.

Functional programming has been on the rise for quite some time now, and rightly so. Many non-functional programming languages had long adopted at least some amount of functional programming principles, and while Java had been lagging behind, it’s finally jumped on the bandwagon with the latest version, Java 8.

Functional programming is closer to mathematics than other programming paradigms such as procedural or object-oriented programming, so as one gains more and more experience on one of them, it gets more difficult for them to grasp the functional programming concepts. Even though I had a C/C++ background using function pointers, and a lot of Javascript experience using callbacks and methods such as Array.map(), I had a hard time understanding LINQ in C#. In that sense, it’s perfectly understandable for me that most Java programmers, even seasoned ones, are shying away from lambdas and streams and prefer to stick to good old lists and for loops in their daily usage.

In the light of that observation, I decided to write this article to help programmers establish a ground on what these “strange” facilities are. I will be explaining what streams and lambda expressions are, and which functional operations are executed and what does it mean to be executed lazily. Hopefully, this article will be helpful to both newcoming Java 8 programmers, and C# programmers who are not familiar with the LINQ API.