[pron]

> Do you mean co-routines / user threads / green threads? I tend to agree it can have a serious performance boost in some cases.

Yes, but in this context, they provide the same performance benefits as the asynchronous techniques mentioned in the article, without all the drawbacks of the cumbersome asynchronous style.

> But saying that actor model is bad practice

The actor model is a general technique for fault-tolerance, and it's great. How it handles concurrency, though, is an orthogonal concern. Akka has asynchronous (callback based) actors, and callbacks are an anti-pattern. Erlang has synchronous (blocking) actors, which are so much simpler, and don't have all the complications associated with asynchronous code.

[noelwelsh]

Erlang has asynchronous message passing by default, on which synchronous message passing can be built.

[Matthias247]

I would agree that in both Akka and Erlang message passing works in an asynchronous way.

For me the difference is more that Akka has a push-style approach to message processing in the receiver (the receive message is automatically called) whereas Erlang and also e.g. the F# Mailboxprocessor use a pull-style appproach (you call receive to fetch a message). I like the latter approach better, because it allows one to start also different asynchronous operations which won't be interrupted by the reception of a new message.

[pron]

That's not what I meant. Message receive in Erlang is blocking (synchronous), just like it is in Go and Quasar. Meaning, it's basically a blocking queue rather than the asynchronous/push-style/callback approach used in Akka.