Is Scala's actors similar to Go's coroutines? -

if wanted port go library uses goroutines, scala choice because inbox/akka framework similar in nature coroutines?

nope, they're not. goroutines based on theory of communicating sequential processes, specified tony hoare in 1978. idea there can 2 processes or threads act independently of 1 share "channel," 1 process/thread puts data , other process/thread consumes. prominent implementations you'll find go's channels , clojure's core.async, @ time limited current runtime , cannot distributed, between 2 runtimes on same physical box.

csp evolved include static, formal process algebra proving existence of deadlocks in code. nice feature, neither goroutines nor core.async support it. if , when do, extremely nice know before running code whether or not deadlock possible. however, csp not support fault tolerance in meaningful way, developer have figure out how handle failure can occur on both sides of channels, , such logic ends getting strewn on application.

actors, specified carl hewitt in 1973, involve entities have own mailbox. asynchronous nature, , have location transparency spans runtimes , machines - if have reference (akka) or pid (erlang) of actor, can message it. people find fault in actor-based implementations, in have have reference other actor in order send message, coupling sender , receiver directly. in csp model, channel shared, , can shared multiple producers , consumers. in experience, has not been of issue. idea of proxy references mean code not littered implementation details of how send message - send one, , wherever actor located, receives it. if node goes down , actor reincarnated elsewhere, it's theoretically transparent me.

actors have nice feature - fault tolerance. organizing actors supervision hierarchy per otp specification devised in erlang, can build domain of failure application. value classes/dtos/whatever want call them, can model failure, how should handled , @ level of hierarchy. powerful, have little failure handling capabilities inside of csp.

actors concurrency paradigm, actor can have mutable state inside of , guarantee of no multithreaded access state, unless developer building actor-based system accidentally introduces it, example registering actor listener callback, or going asynchronous inside actor via futures.

shameless plug - i'm writing new book head of akka team, roland kuhn, called reactive design patterns discuss of , more. green threads, csp, event loops, iteratees, reactive extensions, actors, futures/promises, etc. expect see meap on manning next month.

good luck!