Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Promises are not neutral enough

staltz.com

Post reply on HN
Print view View original

41–50 of 133 posts

Re: Promises are not neutral enough

#41

Post by roguecoder »

This article doesn't even touch on the worst sin of JavaScript Promises: they swallow errors and exceptions, which makes them nearly impossible to test correctly and makes debugging horrifying (if you even notice anything is wrong.)

Promises are a great example with the problems of believing that something good in one language will be good in another. Promises in JavaScript are fighting the language, because JavaScript is fundamentally a collection of isolated but contextual behaviors.

Using Agents to encapsulate callbacks is easier to reason about, easier to test, less likely to swallow errors whole, and doesn't have any of the problems laid out in this article. Unfortunately because it isn't a model popular in any other language, it doesn't have the name recognition Promises do.

Re: Promises are not neutral enough

#42

Post by rictic »

codedokode wrote: post #29
rictic wrote: post #23

Earlier quoted context omitted.

This is a fundamental issue with multitasking, in that an independent task will have its own stack, so errors can't propagate up the stack of the function that started the task. e.g. consider this python code: def start_task(): Thread(do_task).start() What happens if do_task throws an exception? The exception can't propagate up from start_task because start_task may have returned when the exception is thrown. At some…

If you want to have a specific point to catch an exception, you could write something like this: def start_task(): thread = Thread(do_task) thread.set_error_handler(SpecificErrorType, handler) thread.start()

Yes, but this has a natural analogue in promise land:

    function startTask() {
      const promise = doTask();
      promise.catch((e) => {
        if (e instanceof SpecificErrorType) {
          handler(e);
        } else {
          throw e;
        }
      });
    }

Re: Promises are not neutral enough

#43

Post by spion »

_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

This has nothing to do with it. I love promises but they are truly limiting.

Here is an example of how promises limit the power of mobx

https://twitter.com/spion/status/958906847385341952

Another example relevant in node is continuation-local-storage (equivalent to threadlocal storage). Implementing it on top of generators or other "chainable / thenable" abstractions is trivially easy. Implementing it on top of native promises and async/await is impossible without deep hooks into the platform.

More examples here: https://spion.github.io/posts/es7-async-await-step-in-the-wr... (see the second part)

We should've paused on async-await and waited for jhusain's compositional functions: https://github.com/jhusain/compositional-functions

In the meantime generator based libraries would've properly explored the whole breadth of power that co-routines can give you, creating cowpaths to be paved by TC39.

Promises make trade-offs, and they end up with a design that is generally good and can be used well in some number of situations. But not all. Not nearly enough to get first class syntax support that makes them privileged over all other solutions.

Re: Promises are not neutral enough

#44

Post by rictic »

roguecoder wrote: post #41

This article doesn't even touch on the worst sin of JavaScript Promises: they swallow errors and exceptions, which makes them nearly impossible to test correctly and makes debugging horrifying (if you even notice anything is wrong.) Promises are a great example with the problems of believing that something good in one language will be good in another. Promises in JavaScript are fighting the language, because JavaScri…

Can you expand on that? How would an agent-based API propagate exceptions?

Re: Promises are not neutral enough

#45

Post by BillinghamJ »

bfred_it wrote: post #38
codedokode wrote: post #15

I have a feeling the author doesn't understand Promises well. In my opinion, they are in fact designed poorly, but I don't see any problems with points the author describes. He doesn't like that the callback is called immediately - but Promises just represent a result that will be available later and do not guarantee (and should not) when the function will be called. If you want to delay some function call, do it exp…

> While it is expected that the runtime error would float up and terminate the program This will supposedly happen in a future version of node. [1] [1]: https://nodejs.org/dist/latest-v8.x/docs/api/deprecations.ht...

It will happen. Most likely Node 11 I'd estimate - 10 seems a little close for landing it

https://github.com/nodejs/node/pull/15126

Re: Promises are not neutral enough

#46

Post by dmitriid »

- Eager is relatively easy to convert to lazy, if needed. The inverse isn’t true.

- async is relatively easy to turn into sync. The inverse isn’t true.

- no API design is ”neutral”. Any API design is opinionated. Cancelable lazy synchronous promises is just as opinionated a design as the current design.

Re: Promises are not neutral enough

#47

Post by staltz »

_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

Hi. First I'd like to comment that I wrote that blog post literally quickly because I just wanted to convert an informal Twitter thread into a more shareable and digestible format, so I didn't take the time to make it "hackernews comment resistant" if you know what I mean.

On opinionated choices: I try to base that on mathematics. When it comes to async programming, that means equational reasoning and following some basic properties such as composition, associativity, left identity, right identity, etc, see https://github.com/fantasyland/fantasy-land . These would be neutral because math is often neutral. For instance, if intelligent aliens exist, they probably figured out the circle just like we did.

On ideological preferences: there isn't anything free of ideology, so yes I am motivated by some ideology, not unlike influential members of TC39. There, you'll often find opposition to functional programming ideas, even though JS was originally designed with influences from Scheme, and allowed functional programming better than, e.g., Java at the time. See these TC39 notes, for instance: https://github.com/tc39/tc39-notes/blob/master/es8/2017-09/s...

FP ideas are usually opposed because TC39 proposals are driven by concrete use cases, and FP is all about abstractions. FP ideology is that abstractions are good because they accomplish abstract goals, not a single particular concrete goal. That does not play well with the use-case-first process at TC39. So, ideologies.

On "it would hurt the ecosystem": I think by now a lot of people from different language communities recognize the success of RxJava/RxJS/Rx.NET, and it tackles all those complications you mentioned, but for even more complex use cases, because it handles multiple values over time. I'm not arguing that Rx is a silver bullet, I'm just saying the Rx community has first hand experience with solving and teaching solutions to the problems you mentioned in the second paragraph and it's nowhere near "catastrophic".

Re: Promises are not neutral enough

#49

Post by lilactown »

_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

The way that promises are implemented actively hurts the ecosystem. Trying to e.g. create a sound typing of the Promise API is really, really hard because of it's auto-flattening nature. This severely hampers languages like TypeScript, Flow & ReasonML that build on top of JavaScript.

Re: Promises are not neutral enough

#50

Post by camus2 »

codedokode wrote: post #15

I have a feeling the author doesn't understand Promises well. In my opinion, they are in fact designed poorly, but I don't see any problems with points the author describes. He doesn't like that the callback is called immediately - but Promises just represent a result that will be available later and do not guarantee (and should not) when the function will be called. If you want to delay some function call, do it exp…

> This code will just ignore the error. While it is expected that the runtime error would float up and terminate the program - that is what runtime errors are made for.

No, this behavior is consistent with how asynchronous programming works in JS.

    myDiv.addEventListener("click",function(event){
       throw "error";
    });
Nobody would expect that code to terminate a browser tab on error.

> This also makes writing tests more difficult because tests often use exceptions to indicate failure.

Then use async functions, problem solved.

Post reply on HN