7 ms·

I always skip to the async part of JS text because explaining it is a bit like handing a shotgun to a five year old. I think the folks over at risingstack have

I always skip to the async part of JS text because explaining it is a bit like handing a shotgun to a five year old. I think the folks over at risingstack have the best explanations, IMHO. I'm surprised they attempted timeouts in promises with so little text, that's actually pretty dangerous pattern because it glosses over the complexity in actually stopping an in-flight promise. It is VERY easy to end up with hundreds of thousands of unresolved promises with their pattern. Dangerous! There is a great repo on this issue.... aand I can't for the life of me find it. Basically there's a github project that uses generators and passes an atom down through the call stack to ensure everything below the race promise is aware that it is being halted. And even that doesn't handle all the nuances of this pattern. And if anyone knows what github repo I'm talking about, I'll give you ... 50 DKP?

zer 6y ago
Regarding your second point: This sounds similar to .NET‘s CancellationToken. It works very well there. What are those nuances in JavaScript which aren’t handled by it?
- 0xff00ffee 6y ago
  I think you're going to point out that I'm about to demonstrate non-JavaScript nuances, but here are issues I've encountered: Let's take a great of example of where promises are used most often: AJAX. If the endpoint isn't RESTful and there is state on the other end, cancelling a promise requires updating the entire module of the new state. There can be multiple reasons for cancelling, and the code needs to be aware of what is happening beyond a simple timeout. Same thing goes for USB devices (via libusb+ffi) and serial-ports (via serialport). In flight requests can disturb state if cancelled, and it makes the programming very complex to just time-out. One could argue AJAX and hardware programming are outside the domain of JavaScript, but I wouldn't. I guess it is more than a "nuance", it is the observance that cancelling an asynchronous operation in general can have unintended consequences if not handled correctly ... beyond memory leaks from unresolved promises.
galaxyLogic 6y ago
I used to use more "Promises" but now I mostly code with plain callbacks if possible. It is just simpler, less thinking needed. I spend that thinking-budget on other things. One thing that is tricky with async is that nobody tells you if the async function never does what it should. I wish they would add some more built-in support for that in the next JS version. Promises hold promise (pun intended) but they are a bit too complicated for my brain.
- nujabe 6y ago
  Callbacks are a bit too much of an eye sore imo. >One thing that is tricky with async is that nobody tells you if the async function never does what it should Could you clarify this?
  - galaxyLogic 6y ago
    In sync programming if your function does the wrong thing you typically get an error thrown or you get a result which you check for its correctness. But when you call an async-function that is supposed to do something like say write to a file or database maybe there is an error which makes it never do its job, and never call the callback you gave it. But the rest of your program just hums along happily. There is no error. The error does not "happen" but the error is that "something did NOT happen". And when something does not happen you don't get an error or notification saying that something did not happen. You run your program but expected results do not show up in database. But you don't know why, because the problem is that some of your async functions did NOT call something they should have called. It's hard to detect that something does not happen. Some kind of built-in support for callback-timeouts might alleviate this problem.
    - nujabe 6y ago
      The scenario you described is a classic one and I really don't think it's as problematic as you may think. I had to reread it because it sounded too trivial. How about just throwing an error when the async function fails to write to the db? >maybe there is an error which makes it never do its job You can throw an error regardless of the reason why it failed to do its job. If the write to the db does not success, you can throw an error.

zer 6y ago

Regarding your second point: This sounds similar to .NET‘s CancellationToken. It works very well there. What are those nuances in JavaScript which aren’t handled by it?

0xff00ffee 6y ago
I think you're going to point out that I'm about to demonstrate non-JavaScript nuances, but here are issues I've encountered: Let's take a great of example of where promises are used most often: AJAX. If the endpoint isn't RESTful and there is state on the other end, cancelling a promise requires updating the entire module of the new state. There can be multiple reasons for cancelling, and the code needs to be aware of what is happening beyond a simple timeout. Same thing goes for USB devices (via libusb+ffi) and serial-ports (via serialport). In flight requests can disturb state if cancelled, and it makes the programming very complex to just time-out. One could argue AJAX and hardware programming are outside the domain of JavaScript, but I wouldn't. I guess it is more than a "nuance", it is the observance that cancelling an asynchronous operation in general can have unintended consequences if not handled correctly ... beyond memory leaks from unresolved promises.

galaxyLogic 6y ago

I used to use more "Promises" but now I mostly code with plain callbacks if possible. It is just simpler, less thinking needed. I spend that thinking-budget on other things. One thing that is tricky with async is that nobody tells you if the async function never does what it should. I wish they would add some more built-in support for that in the next JS version. Promises hold promise (pun intended) but they are a bit too complicated for my brain.

nujabe 6y ago
Callbacks are a bit too much of an eye sore imo. >One thing that is tricky with async is that nobody tells you if the async function never does what it should Could you clarify this?
- galaxyLogic 6y ago
  In sync programming if your function does the wrong thing you typically get an error thrown or you get a result which you check for its correctness. But when you call an async-function that is supposed to do something like say write to a file or database maybe there is an error which makes it never do its job, and never call the callback you gave it. But the rest of your program just hums along happily. There is no error. The error does not "happen" but the error is that "something did NOT happen". And when something does not happen you don't get an error or notification saying that something did not happen. You run your program but expected results do not show up in database. But you don't know why, because the problem is that some of your async functions did NOT call something they should have called. It's hard to detect that something does not happen. Some kind of built-in support for callback-timeouts might alleviate this problem.
  - nujabe 6y ago
    The scenario you described is a classic one and I really don't think it's as problematic as you may think. I had to reread it because it sounded too trivial. How about just throwing an error when the async function fails to write to the db? >maybe there is an error which makes it never do its job You can throw an error regardless of the reason why it failed to do its job. If the write to the db does not success, you can throw an error.