3 ms·

Javascript is single-threaded so those sort of bugs can't ever happen.

• dwohnitmok 6y ago
  No they still can. You can still have concurrency bugs in the absence of parallelism (the classic example of why concurrency and parallelism are not the same thing) as long as you have a concurrent API (which the Elm architecture is an example of). The basic problem is that there is an undefined delay between a message is issued and when `update` is called on the message which can be caused by other messages being in the queue. Here's an example with subscriptions and views. Time 0: A subscription arrives with message `A` which is added to the message queue in Elm's runtime. Note that one "tick" in Elm's runtime has not yet passed so we don't process the queue just yet (to see why this can happen we can either look at Elm's source code or note that the fact that Elm doesn't lose a subscription even if updates are busy processing forces there to be a message queue of length > 1). Time 1: Your view sends a message `B` which contains a snapshot of the model `M0` at Time 1. `B` is added to the message queue. Time 2: Your update function pops off the message queue and processes `A`, resulting in a new model `M1`. Time 3: The Elm runtime processes another tick and sees no new messages from either views or subscriptions. Time 4: Since the runtime is now done examining subscriptions and view messages, your update function pops off the message queue and processes `B`, resetting the model back to `M0`. At the end of this sequence you effectively haven't handled the subscription at all, and all this is on a single thread.