Quasar is going the right direction - writing synchronous code is better - the code is simpler and cleaner. There is no inherent performance penalty in synchronous approach, it's just the runtime systems of many popular languages make it so - statically allocated stack, and some penalty of context switch via system call. In addition to the languages mentioned in the article (Go, Clojure core.async, Erlang), Gambit Scheme deserves to be mentioned, winch can spawn millions of lightweight (green) threads. Also there was Stackless Python.
BTW, no need to describe the implementation in terms of continuations. It's just enough (I think) to allocate function activation records on heap instead of statically allocated stack. (AFAIK continuations are also implemented similarly, although what I've read about Go, their call stack management is something more complex)
Also, I think the "actor model" is not the final solution for scalable distributed programming, it's just some initial, and IMHO pretty clumsy step. We will have better approaches soon.
I feel like Actor is a quantum leap ahead of all the previous and current paradigms, like Promise and Future and Async. What do you think makes it clumsy and why do you think we have something better in store?
The problem, I suspect, is that there isn't really one formal "actor" model that everyone agrees on. People have used it to describe formal models like CSP and linear logic, practical systems like the Erlang VM and Go's green threading implementation, and capability-based systems like the (provably secure) SEL4; these are not the same thing. And, not to pick on you specifically, this is exacerbated by confusingly referring to "promises, futures, and async" as "paradigms." Promises and futures are for the most part identical, and I don't see how you can meaningfully call them "paradigms"--they're just APIs. "Async" (async what?) is maybe abstract enough that I'd be willing to call it a "paradigm," but I don't see how actors don't also fall into that category.
could you point to a place where anyone's said that Go, or any other CSP system, are Actor systems? That would be interesting to see.
Promises and futures are not actually identical; and they're paradigms, because they are concepts shared across a large number of different languages. 'Async' is the P in CSP, as in C# (called 'async'), and as in ES7 (https://github.com/lukehoban/ecmascript-asyncawait). Hope this helps you.
BTW, no need to describe the implementation in terms of continuations. It's just enough (I think) to allocate function activation records on heap instead of statically allocated stack. (AFAIK continuations are also implemented similarly, although what I've read about Go, their call stack management is something more complex)
Also, I think the "actor model" is not the final solution for scalable distributed programming, it's just some initial, and IMHO pretty clumsy step. We will have better approaches soon.