- the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming (as in programming with mathematical functions), then you wouldn't want to go back to a language that makes that impossible ;-)
- Akka actors are not the only game in town for processing data, you can also use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency often requires multiple solutions because there's no silver bullet and Go's channels suck compared with what you can do with a well grown streaming solution
- Scala's Future are not meant for "hiding threads" and 1:1 multi-threading is actually simpler to reason about, because if that fancy M:N runtime starts being unsuitable (because lets be honest, most M:N platforms are broken in one way or another), then you can't fix it by choosing a more appropriate solution without changing the platform completely
- Your devs are maybe lazy or maybe they don't give a fuck, but given that you're supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it's time to invest in their education or hire new developers, because the programming language is the least of your problems
- Paul Phillips still works with Scala and he most likely hates languages like Go, so when you mention him or his presentation, it definitely cannot be in support of Go
I don't understand the claim that Akka actors are both impure and non-deterministic.
If your actor is communicating only through its inbox, then it is both pure and deterministic. Given the same set of messages in the same order, you arrive at the same actor state. Sure, you can do wacky things with side-effects, but that's not akka's fault.
> in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming
This sounds a lot like the "no true Scotsman" fallacy. I'm not attacking your argument here, but perhaps you could expound upon that first point and clarify.
> Given the same set of messages in the same order, you arrive at the same actor state
You just described object identity (see [1]), which are objects whose state is determined by the history of the messages received. An object with identity is stateful, side-effectful and impure by definition.
So no, an actor is almost never pure or deterministic. I'd also like to emphasize determinism here, because you can never rely on a message ordering, given their completely asynchronous nature, so you get something much worse than OOP objects with identity.
> This sounds a lot like the "no true Scotsman" fallacy
I'm talking about my experience. Given that I'm currently a consultant / contractor, I have had a lot of experience with commercial Scala projects initiated by other companies. And in general the projects that use Akka actors are projects that have nothing to do with functional programming.
This happens for a lot of reasons, the first reason being that most people are not in any way familiar with functional programming, or what FP even is for that matter. Not really surprising, given that most Scala developers tend to be former Java/Python/Ruby developers that get lured by Akka actors and once an application grows, it's hard to change it later. Evolution to functional programming happens in a web service model where new components get built from scratch.
But the second reason is more subtle. Functional programming is all about pushing the side-effects at the edges of your program. And if you want to combine the actor model with functional programming, you have to model your actors in such a way as to not contain any business logic at all (e.g. all business logic to be modeled by pure functions, immutable data-structures and FP-ish streaming libraries), evolved only with `context.become` (see [2]). So such actors should be in charge only with communications, preferably only with external systems. This doesn't happen because it's hard to do, because developers don't have the knowledge or the discipline for it and because it then raises the question: why use actors at all?
Because truth be told, while actors are really good at bi-directional communications, they suck for unidirectional communications, being too low level. And if we're talking about communicating over address spaces, for remoting many end up with other solutions, like Apache Kafka, Zookeeper, etc.
On combining Akka actors with functional programming, I made a presentation about it if interested (see [3]).
- the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual functional programming (as in programming with mathematical functions), then you wouldn't want to go back to a language that makes that impossible ;-)
- Akka actors are not the only game in town for processing data, you can also use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency often requires multiple solutions because there's no silver bullet and Go's channels suck compared with what you can do with a well grown streaming solution
- Scala's Future are not meant for "hiding threads" and 1:1 multi-threading is actually simpler to reason about, because if that fancy M:N runtime starts being unsuitable (because lets be honest, most M:N platforms are broken in one way or another), then you can't fix it by choosing a more appropriate solution without changing the platform completely
- Your devs are maybe lazy or maybe they don't give a fuck, but given that you're supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it's time to invest in their education or hire new developers, because the programming language is the least of your problems
- Paul Phillips still works with Scala and he most likely hates languages like Go, so when you mention him or his presentation, it definitely cannot be in support of Go