4 ms·
Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the
by spinningslate 3y ago
Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the caller, not the callee. Which means it's there where you need it and out of the way when you don't. With async/await, the decision is made by a function implementer somewhere down the stack, quite probably in 3rd party code. As the caller you get no choice because coloured functions [1]. You have to deal with concurrency whether your app needs it or not.
--
[0] By thread I mean the general concept, not specifically OS threads. In this case it includes the fine-grained processes offered by the BEAM VM that underpins Elixir and Erlang.
[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- zelphirkalt 3y agoIs thread-based the right terminology for Erlang's lightweight processes? I guess the pattern is comparable.
- toast0 3y agoThread-based concurrency is a big part of it, but another nice thing is that mostly synchronous APIs in Erlang are built upon an asynchronous send, followed by an immediate wait. If/when you decide that you don't want the synchronous API, you can usually relatively easily separate the two parts, and process them differently, without having to spawn more threads to do each thing synchronously and then join the threads the way you want. Building on asynchronous sends also makes it conceptually the same to make a local request vs a request on a remote node, although with some additional failure conditions that don't usually make sense to worry about on a single node system.