3 ms·

I also wonder why async/await became the dominant paradigm, with Python, JavaScript, and Rust borrowing it from C# as far as I can tell. I buy the "what color

by chubot 8y ago

I also wonder why async/await became the dominant paradigm, with Python, JavaScript, and Rust borrowing it from C# as far as I can tell. I buy the "what color is your function?" argument: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... If you look at Python, it has spawned sort of a parallel standard library / language around async/await. For example, as of Python 3.7 contextlib apparently has an AsyncContextManager ("with"). There are async versions of the "itertools" module floating around. Although, Go is more like Erlang in that it doesn't suffer from this problem. But Python and JS are two of the most popular languages in the world, so I guess that means async/await "won" ?

bsaul 8y ago
"I also wonder why async/await became the dominant paradigm" Having only followed the discussion about concurrency on the swift language, it seems async/await is clearly more straightforward to implement starting from a regular C-stack like compiled language, than an erlang-like system with its VM looking a lot like an OS of its own. Abour Rust, i've seen a few actor-based frameworks, and i'm really putting a lot of hope in this language, since it seems to have both the taste for high-level & hard to implement features, and the community that goes with it. Unfortunately, here too i think the core language team needs to be heavily involved for this pattern to succeed. In the meantime, i think i've got no other choice than to start using elixir+OTP or erlang+OTP.