Yes, but they do them differently. BeeHive is much more opinionated about the message (must be event and has an enveloper) and the Basic Data Structures.
Also BeeHive avoids stateful actors. State is always persistent in HA queues or Basic Data Structure stores.
I thought Rails had taught us that extremely opinionated infrastructures are doomed to at best be influential, but not widely used.
Sometimes actors have to be stateful. Sometimes they should be the interface to large, complex computations that take 20 minutes to run.
The market is choke full of techs that solve very narrow cloud problems. What we need is something that isn't so terribly narrow. Microservices is very, very narrow. Even people working for Fred George admit to that.
I'm having a hard time parsing this—Rails is something I would consider to be both highly opinionated and widely used, but its unclear where your statement falls. I'm not crazy about some (most?) of the opinions, but that's a matter of some debate.
> Microservices is very, very narrow. Even people working for Fred George admit to that.
Its hard to make this statement without first agreeing to a definition of microservices. I'm not convinced there's wide agreement to such a definition yet.
How exactly do you mean "stateful actor"? Whether an Akka actor has a state is actually up to you!? E.g. you could have your router fire up a new actor to process each request up to a maximum number of n concurrent actors etc...