3 ms·

I find async/await to be easier to use than alternatives. I see two categories: - A. Async/await - compiler saves and resumes functions. - B. Message based -

I find async/await to be easier to use than alternatives. I see two categories: - A. Async/await - compiler saves and resumes functions. - B. Message based - Golang, Erlang, threads with messaging. With category A, I can use my IDE to jump to every function that is called and easily follow the computation. With category B, all of these connections happen at runtime with messages. When you have a tree of tasks all which may save/resume many times, async/await it easier to understand than launching a thread per IO event.

jeremyjh 6y ago
This a confused notion. A useful way to think of Go and Erlang is that they automatically and transparently insert async/await each time you call a function that performs I/O. Messaging between different application tasks is completely orthogonal and can have use cases in languages with async/await as well.
- justsomeuser 6y ago
  I probably should have put the categories as: A. Implicit messaging using the languages function syntax (async/await). B. Direct messaging using a message passing feature of the runtime (Erlang, Golang) Note: I mean "messaging" in the context of a single OS process, that possibly has many threads (so within a single language runtime). Async/await is still implicit messaging, but it appears like a regular function call - which in my opinion is easier to understand. Using function args/return for input/output is something every developer already knows. In contrast, Erlang and Golang require you to use some type of messaging feature in addition to functions. > A useful way to think of Go and Erlang is that they automatically and transparently insert async/await each time you call a function that performs I/O The part they are missing from async/await is the ability to easily get return values without messaging, and do this recursively for a large tree of functions. E.g. getting a return value from `go x()` requires messaging, but with async/await you could do `const p = x(); const ret = (await p); // return value received at a later time with no messaging.` Both of them will require you to create some type of messaging topology to return the values (which makes your program a mixture of (regular functions + messaging features) vs async/awaits "everything looks like a function").
  - jeremyjh 6y ago
    > The part they are missing from async/await is the ability to easily get return values without messaging, and do this recursively for a large tree of functions. No, they do not. In Elixir for example if I call: bytes = File.read!("filename.txt") `bytes` will have the data returned from the function call immediately, with no need for message passing or awaiting the result. Under the hood, it is still asynchronous evented I/O. If I want to explicitly await for flow control reasons (await all of or one of multiple events) that is available in the stdlib in the `Task` module. E.g. t1 = Task.async(fn -> do_this_thing() end) t2 = Task.async(fn -> do_this_other_thing() end) Task.await_many([t1, t2]) You can accomplish most things without ever calling send/receive or writing your own gen_server etc.
    - justsomeuser 6y ago
      I see, I did not know that. Last time I used Erlang (pre-Elixir), the `bytes` example would require you to set up a request/response with a blocking `receive`.
    - justsomeuser 6y ago
      Although this emulates async/await (AA), under the the "async" emulated functions is message passing that must keep track of the connection between requests and responses at runtime (E.g. with state mapping request ids to response ids). I think the key issue is that the inputs and outputs are disconnected in the static program text (and only connected dynamically at runtime). Two contexts that matter for understanding how a system transitions between states are: 1. Program editing/reading. 2. Runtime. I think AA is superior for understanding the system as a whole in both these contexts, because at edit time the IDE jump to def/show all usages allows you to understand every function that will be called, and at runtime you can get a stack trace to understand where the current function came from, and where it is going. With message passing runtimes, both 1 and 2 require extra mental models on the part of the programmer, because they also need to understand the network topology (which either is not possible statically, or requires extra tooling on top of functions). Message passing breaks down your system into CSP's, which makes it easy to understand each sync process, but hard to understand the whole system, as the same program-writing-process that allowed you to break down your components is working against you when you need to put them together again to understand the whole system. I could be wrong as I have not used modern IDE's or debugging tools with message passing runtimes lately.

jeremyjh 6y ago

This a confused notion. A useful way to think of Go and Erlang is that they automatically and transparently insert async/await each time you call a function that performs I/O. Messaging between different application tasks is completely orthogonal and can have use cases in languages with async/await as well.

justsomeuser 6y ago
I probably should have put the categories as: A. Implicit messaging using the languages function syntax (async/await). B. Direct messaging using a message passing feature of the runtime (Erlang, Golang) Note: I mean "messaging" in the context of a single OS process, that possibly has many threads (so within a single language runtime). Async/await is still implicit messaging, but it appears like a regular function call - which in my opinion is easier to understand. Using function args/return for input/output is something every developer already knows. In contrast, Erlang and Golang require you to use some type of messaging feature in addition to functions. > A useful way to think of Go and Erlang is that they automatically and transparently insert async/await each time you call a function that performs I/O The part they are missing from async/await is the ability to easily get return values without messaging, and do this recursively for a large tree of functions. E.g. getting a return value from `go x()` requires messaging, but with async/await you could do `const p = x(); const ret = (await p); // return value received at a later time with no messaging.` Both of them will require you to create some type of messaging topology to return the values (which makes your program a mixture of (regular functions + messaging features) vs async/awaits "everything looks like a function").
- jeremyjh 6y ago
  > The part they are missing from async/await is the ability to easily get return values without messaging, and do this recursively for a large tree of functions. No, they do not. In Elixir for example if I call: bytes = File.read!("filename.txt") `bytes` will have the data returned from the function call immediately, with no need for message passing or awaiting the result. Under the hood, it is still asynchronous evented I/O. If I want to explicitly await for flow control reasons (await all of or one of multiple events) that is available in the stdlib in the `Task` module. E.g. t1 = Task.async(fn -> do_this_thing() end) t2 = Task.async(fn -> do_this_other_thing() end) Task.await_many([t1, t2]) You can accomplish most things without ever calling send/receive or writing your own gen_server etc.
  - justsomeuser 6y ago
    I see, I did not know that. Last time I used Erlang (pre-Elixir), the `bytes` example would require you to set up a request/response with a blocking `receive`.
  - justsomeuser 6y ago
    Although this emulates async/await (AA), under the the "async" emulated functions is message passing that must keep track of the connection between requests and responses at runtime (E.g. with state mapping request ids to response ids). I think the key issue is that the inputs and outputs are disconnected in the static program text (and only connected dynamically at runtime). Two contexts that matter for understanding how a system transitions between states are: 1. Program editing/reading. 2. Runtime. I think AA is superior for understanding the system as a whole in both these contexts, because at edit time the IDE jump to def/show all usages allows you to understand every function that will be called, and at runtime you can get a stack trace to understand where the current function came from, and where it is going. With message passing runtimes, both 1 and 2 require extra mental models on the part of the programmer, because they also need to understand the network topology (which either is not possible statically, or requires extra tooling on top of functions). Message passing breaks down your system into CSP's, which makes it easy to understand each sync process, but hard to understand the whole system, as the same program-writing-process that allowed you to break down your components is working against you when you need to put them together again to understand the whole system. I could be wrong as I have not used modern IDE's or debugging tools with message passing runtimes lately.