2 ms·

In the somewhat broken sense in which "async" and "sync" are now used courtesy of Node's propagandization of the terms, all Erlang functions are async. Any of t

by jerf 5y ago

In the somewhat broken sense in which "async" and "sync" are now used courtesy of Node's propagandization of the terms, all Erlang functions are async. Any of them can do some IO, and the runtime will switch away from the Erlang process to do the IO and run other Erlang processes, and then once the IO is done it automatically comes back to finish the process' task. I call it somewhat broken because this sense conflates the question of how the code is written with how the code is executed, which creates a semantic blind spot in which a programmer that has only used this paradigm becomes incapable of conceptualizing a runtime system in which the code is written "synchronously" but actually run "asynchronously". But it's a popular definition and you need to understand that people use the term to mean both the fact that a function is written with explicit "async/await" annotations and that it is run that way, and that you need to very carefully explain that these two things are not actually as tied together as they think because it is a foreign thought if that is all they know, which is large and probably growing number of programmers right now. I don't mean anything mean by that statement, I'm just being descriptive. I remember my days of thinking line numbers in programs were fundamental and it would be impossible to conceive of a programming language lacking them.

dragonwriter 5y ago
> In the somewhat broken sense in which "async" and "sync" are now used courtesy of Node's propagandization of the terms, all Erlang functions are async. > Any of them can do some IO, and the runtime will switch away from the Erlang process to do the IO and run other Erlang processes, and then once the IO is done it automatically comes back to finish the process' task. I don't think that's the common use, nor is it particularly true even in that use, since Erlang’s main runtime is M:N threaded so that up to the limits of parallelism on the host machine (or the parallelism limit set when starting the runtime), Erlang processes are parallel to start with, though it is true that the runtime will also use IO and certain other opportunities to swap the running Erlang process in a given native thread when at the parallelism limit.) It's worth noting that in that (badly broken) definition, all Ruby and Python functions are async (because the runtime, even with the GIL/GVL, swaps running threads on IO and certain other opportunities), which is particularly confusing in Python's case, because Python also has colored functions with async/await (that is, Python has the kind of “async” that has generally defined the term, especially in the context of colored functions, since C# popularized the term.) It is true there is another older use of the term, which remains popular in the absence of the “colored function” context which also applies to Node, but that definition doesn't refer to when the runtime takes the opportunity to switch tasks but instead refers to having nonblocking operations (mainly IO) with callback/promise (or, later, async/await) semantics allowing concurrency within a single logical thread/process of execution. Ruby, in that sense has async libraries despite having not having sync/await syntax. Python had async libraries before async/await, Node is all async even before async/await, and Erlang is still entirely synchronous, relying on explicit separate logical processes for both concurrency and parallelism.

by jerf 5y ago

dragonwriter 5y ago

> In the somewhat broken sense in which "async" and "sync" are now used courtesy of Node's propagandization of the terms, all Erlang functions are async. > Any of them can do some IO, and the runtime will switch away from the Erlang process to do the IO and run other Erlang processes, and then once the IO is done it automatically comes back to finish the process' task. I don't think that's the common use, nor is it particularly true even in that use, since Erlang’s main runtime is M:N threaded so that up to the limits of parallelism on the host machine (or the parallelism limit set when starting the runtime), Erlang processes are parallel to start with, though it is true that the runtime will also use IO and certain other opportunities to swap the running Erlang process in a given native thread when at the parallelism limit.) It's worth noting that in that (badly broken) definition, all Ruby and Python functions are async (because the runtime, even with the GIL/GVL, swaps running threads on IO and certain other opportunities), which is particularly confusing in Python's case, because Python also has colored functions with async/await (that is, Python has the kind of “async” that has generally defined the term, especially in the context of colored functions, since C# popularized the term.) It is true there is another older use of the term, which remains popular in the absence of the “colored function” context which also applies to Node, but that definition doesn't refer to when the runtime takes the opportunity to switch tasks but instead refers to having nonblocking operations (mainly IO) with callback/promise (or, later, async/await) semantics allowing concurrency within a single logical thread/process of execution. Ruby, in that sense has async libraries despite having not having sync/await syntax. Python had async libraries before async/await, Node is all async even before async/await, and Erlang is still entirely synchronous, relying on explicit separate logical processes for both concurrency and parallelism.