Making the move from Scala to Go
Some notes:<p>- the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn&#x27;t orthogonal either, since an actor&#x27;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&#x27;s a high probability that you never did functional programming; and if you did actual <i>functional programming</i> (as in programming with mathematical functions), then you wouldn&#x27;t want to go back to a language that makes that impossible ;-)<p>- 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&#x27;s no silver bullet and Go&#x27;s channels suck compared with what you can do with a well grown streaming solution<p>- Scala&#x27;s Future are not meant for &quot;hiding threads&quot; 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&#x27;t fix it by choosing a more appropriate solution without changing the platform completely<p>- Your devs are maybe lazy or maybe they don&#x27;t give a fuck, but given that you&#x27;re supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it&#x27;s time to invest in their education or hire new developers, because the programming language is the least of your problems<p>- 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