3 ms·

I agree and claim the burden is on those who say "it's fine, actually" to rebut the definitive article[async:0] on the subject: [await:0] https://journal.stuff

I agree and claim the burden is on those who say "it's fine, actually" to rebut the definitive article[async:0] on the subject: [await:0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... (read it whenever you would like, it's good I Promise). If you've only ever used Javascript, it's tempting to think this is some fact of nature, rather than bad language design.

johannes1234321 5y ago
While it is right, that the red/blue distinction is annoying at times it is the consequence out of the event-loop based approach created in 1995. Any other solution would have broken that more. It is assumed that the code we have is single threaded. That not being the case anymore leads to tons of concurrency issues. Right now I know that all my code, till the next await, will run (mostly) uninterrupted by external influence. No locking needed, nothing will change behind my back etc. In a greenfield environment things certainly would look different, but unfortunately we are tied to past decisions till browser vendors decide to create an alternate universe (well, webassembly ...) and that has enough spread to rely on. But for that one would need agreement what that better future would be.
- anonymoushn 5y ago
  This isn't true. If you had stackful coroutines or something equivalent, you would be able to do all the things this thing does and you wouldn't have to pepper your callers and callers' callers with "await" whenever you add an operation that may take some time to a function for the first time. We had this in Python and still have it in Lua, C, Zig, and so on, but the world has mostly gone the other way.
  - samatman 5y ago
    I happen to be working on an application which is largely written in Lua and uses the same event loop (libuv) as Node. I can confirm that with careful engineering, application code doesn't have to suffer from the color problem. Fundamentally the trick is to yield after creating a callback, and resume into that callback when the thread has more data to process. A `foo:bar():baz():bux()` chain can pause execution in any of those methods and the user doesn't have to know which (some knowledge of whether this will happen /at all/ is required, only because you need a coroutine since Lua can't yield the main thread). This isn't built-in, need to start with something like BEAM for that, but it's a nice sweet spot.
  - poink 5y ago
    I think the issue they were getting at is code like this: function doSomething(doSomethingElse) { internalState.setUp(); doSomethingElse(); internalState.tearDown(); } Right now, you can safely assume this whole thing will execute to completion without anything else happening in the interim, so a lot of existing JS makes that assumption. If `doSomethingElse` can yield while other code executes the assumption becomes invalid.
laurencerowe 5y ago
It's worth reading that excellent article alongside Glyph's excellent article from the opposite perspective: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html A few languages avoid the pitfalls of threads, like Rust where its ownership system protects you.
- anonymoushn 5y ago
  This is a nice post. Off the top of my head, I can't think of any ways of avoiding this issue. Even Rust doesn't really avoid it because different requests could plausibly create their own representations of the payee and payer.
  - laurencerowe 5y ago
    I think Rust avoids this issue because it limits you to a single mutable reference. So even if each thread constructed its own payee and payer, their underlying balances would still reference the same shared state so only one thread at a time would be allowed a mutable reference to payee and payer balances.
    - anonymoushn 5y ago
      It doesn't limit you to a single in-memory representation of each entry in a remote database.
      - IshKebab 5y ago
        You could probably do it for a key value store, but I think it would take a custom database to do it for a relational database.
      - laurencerowe 5y ago
        (The above comment was changed. When I replied it was talking about different threads reading from a database.) In that case you’d be relying on the database rather than the programming language to manage shared state. (The article is more about how to safely manage shared state within a process.)

johannes1234321 5y ago

While it is right, that the red/blue distinction is annoying at times it is the consequence out of the event-loop based approach created in 1995. Any other solution would have broken that more. It is assumed that the code we have is single threaded. That not being the case anymore leads to tons of concurrency issues. Right now I know that all my code, till the next await, will run (mostly) uninterrupted by external influence. No locking needed, nothing will change behind my back etc. In a greenfield environment things certainly would look different, but unfortunately we are tied to past decisions till browser vendors decide to create an alternate universe (well, webassembly ...) and that has enough spread to rely on. But for that one would need agreement what that better future would be.

anonymoushn 5y ago
This isn't true. If you had stackful coroutines or something equivalent, you would be able to do all the things this thing does and you wouldn't have to pepper your callers and callers' callers with "await" whenever you add an operation that may take some time to a function for the first time. We had this in Python and still have it in Lua, C, Zig, and so on, but the world has mostly gone the other way.
- samatman 5y ago
  I happen to be working on an application which is largely written in Lua and uses the same event loop (libuv) as Node. I can confirm that with careful engineering, application code doesn't have to suffer from the color problem. Fundamentally the trick is to yield after creating a callback, and resume into that callback when the thread has more data to process. A `foo:bar():baz():bux()` chain can pause execution in any of those methods and the user doesn't have to know which (some knowledge of whether this will happen /at all/ is required, only because you need a coroutine since Lua can't yield the main thread). This isn't built-in, need to start with something like BEAM for that, but it's a nice sweet spot.
- poink 5y ago
  I think the issue they were getting at is code like this: function doSomething(doSomethingElse) { internalState.setUp(); doSomethingElse(); internalState.tearDown(); } Right now, you can safely assume this whole thing will execute to completion without anything else happening in the interim, so a lot of existing JS makes that assumption. If `doSomethingElse` can yield while other code executes the assumption becomes invalid.

laurencerowe 5y ago

It's worth reading that excellent article alongside Glyph's excellent article from the opposite perspective: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html A few languages avoid the pitfalls of threads, like Rust where its ownership system protects you.

anonymoushn 5y ago
This is a nice post. Off the top of my head, I can't think of any ways of avoiding this issue. Even Rust doesn't really avoid it because different requests could plausibly create their own representations of the payee and payer.
- laurencerowe 5y ago
  I think Rust avoids this issue because it limits you to a single mutable reference. So even if each thread constructed its own payee and payer, their underlying balances would still reference the same shared state so only one thread at a time would be allowed a mutable reference to payee and payer balances.
  - anonymoushn 5y ago
    It doesn't limit you to a single in-memory representation of each entry in a remote database.
    - IshKebab 5y ago
      You could probably do it for a key value store, but I think it would take a custom database to do it for a relational database.
    - laurencerowe 5y ago
      (The above comment was changed. When I replied it was talking about different threads reading from a database.) In that case you’d be relying on the database rather than the programming language to manage shared state. (The article is more about how to safely manage shared state within a process.)