←back to thread

A Few Words About Async

(yoric.github.io)
82 points vinhnx | 2 comments | 02 Nov 25 01:10 UTC | HN request time: 0.493s | source
Show context
travisgriggs ◴[02 Nov 25 05:24 UTC] No.45788011[source]▶
That was “quite a few” words. I wish the author had taken more time with Elixir/Erlang.

Languages like rust/python that use lots of reserved keywords, especially for control flow seem to have reached for that arrow to solve the “event loop” problem as described.

In BEAM languages, that very event loop stays front and center, you don’t have this awkward entanglement between reserved keywords and event loop. If you want another chunk of thing to happen later because of an event, you just arrange for an event of that nature to be delivered. No callbacks. No async coloring. Just events. The solution to the event problem is to double down and make your event loop more generally usable.

replies(1): >>45790783 #
evnc ◴[02 Nov 25 14:57 UTC] No.45790783[source]▶
Interesting. Does that mean if you want to say, make an asynchronous http request, you do something like “fire_event(HttpRequestEvent(…))” which returns immediately, and somewhere else define a handler like “on_event(HttpResponseEvent, function (event) { … })” ? So you kind of have to manually break your function up into a state machine composed of event handlers? How do you associate a given HttpResponseEvent with a specific HttpRequestEvent?
replies(2): >>45791510 #>>45791564 #
koakuma-chan ◴[02 Nov 25 16:37 UTC] No.45791510[source]▶
Isn't that just callback
replies(1): >>45791595 #
travisgriggs ◴[02 Nov 25 16:47 UTC] No.45791595[source]▶
It is a callback of sorts. But most languages do callbacks with some sort of anonymous closure mechanism (or more primitively, pass function pointer/identifiers). What makes BEAM interesting is its prevalence of generalizing callbacks themselves as more events (messages).
replies(1): >>45792196 #
1. koakuma-chan ◴[02 Nov 25 18:11 UTC] No.45792196[source]▶
You can also define a callback function in, e.g., JavaScript, and pass its name instead of an anonymous closure. Does "BEAM" do anything that JavaScript can't or doesn't?
replies(1): >>45793423 #
2. Yoric ◴[02 Nov 25 21:02 UTC] No.45793423[source]▶
There are a few very large features that BEAM offers that, as far as I can tell, no other industrial language/VM implements. In particular, BEAM is meant for distributed computation.

You can spawn new processes, communicate between processes (which don't have to be on the same computer), sending any kind of data between them including closures.

BEAM also has an error model designed to handle concurrent and distributed failures, e.g. a process may fail and another process (which, again, may or may not be on the same machine) monitoring it may decide to restart it, or to do some recovery, etc.

BEAM builds into it a number of the features for which we use orchestration, observability, just simpler and (generally) more flexible. And this is a platform that has been used in the industry since the 90s.