VAvanderZwan·Nov 24, 2024
I'm a little annoyed with the repeated claim in the article that "threads" do not exist in JavaScript when the MDN page on web workers[0] starts with:
> Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application.
Sure, it's not like a unix thread, it's message-passing based instead. Because event-based concurrency came first, and so the natural way to add threads to it was to make them message-passing based. Given that the author expresses their love of the actor model makes it extra surprising they don't mention it, since it seems to be pretty much what they want semantically speaking.
If you want to avoid promises you can also have lots of fun with workers and message channels[1] to implement your own concurrency approaches.
What I'm even more annoyed by is
Read the rest
that everyone always acts like Nathaniel J. Smith invented structured concurrency. There's an entire field of overlooked concurrency paradigms in the family of dataflow programming languages[2], which goes back all the way to the eighties. My personal recent-ish favorite among them being Céu[3][4]. Funny enough it's also yet another language with a completely different take on what "async" and "await" mean.
Céu an imperative language centered where the concurrency used both asynchronous events and sychronous ones. The former represents external events. The latter internal ones.
Code flow can be split into synchronous concurrent paths by writing out each path directly, similar to if .. else .. branches. Instead of "branches" they're called "trails", and started with par/or and par/and as keywords.
par/or do
loop do
await 1s;
_printf("Hello ");
await 1s;
_printf("World!\n");
end
with
await async do
emit 10s;
end
end
Trails are visited in lexical order. If an "await" keyword is encountered the trail is suspended until the event it waits for fires. This is the benefit of synchronous, single-threaded concurrency: have the benefit of allowing the order in which events fire deterministic and expressible in lexical order.
As mentioned, synchronous events represent external inputs. From the perspective of a single module of single-threaded code. they're queued up and get resolved one at a time after the current series of synchronous events finishes and all activated trails in the module are suspended (i.e. awaiting another external event to wake one or more of them in lexical order).
The "async" keyword exists solely to simulate such an asynchronous external event inside the code. In the above example, the "emit 10s" simulates passing 10 seconds of time (and could also have been written as a simple "await 5s", but then it wouldn't have demonstrated the async keyword).
So in the above example, the first trail is entered, starting a loop. Then at each "await 1s" it suspends until one second has passed, after which it resumes from where it awaited. The second trail is entered after the first trails suspends the first time, then suspends for ten seconds. After that the second trail finishes. Because we split into concurrent trails using "par/or", all trails are aborted whenever any trail finishes. This means that we should have printed "Hello World!" five times. However, if the two trails had been written in reverse order:
par/or do
await async do
emit 10s;
end
with
loop do
await 1s;
_printf("Hello ");
await 1s;
_printf("World!\n");
end
end
... the first trail would have finished first, aborting the last "await 1s" of the second trail, resulting in one half finished "Hello " without a newline.
The neat thing is that all of the synchronous concurrency can be compiled down to a very minimal finite state machine with microscopic memory overhead, making it usable in embedded contexts.
(Tangent: the above is the old syntax btw, it is currently being rewritten into a version called Dynamic Céu with more features, and a different syntax whose terminology is also more in line with what the mainstream consensus is for various concurrency terms[5][6]).
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
[1] https://developer.mozilla.org/en-US/docs/Web/API/MessageChan...
[2] https://en.wikipedia.org/wiki/Dataflow_programming
[3] https://github.com/ceu-lang/ceu
[4] https://ceu-lang.github.io/ceu/out/manual/v0.30/
[5] https://github.com/fsantanna/dceu?tab=readme-ov-file#the-pro...
[6] https://github.com/fsantanna/dceu/blob/main/doc/manual-out.m...