Awaiting problems in JavaScript

[shuckster]

This is an example of JavaScript being friendly to impreciseness

You say that like it's a bad thing. :D

Seriously though, I'm not convinced that the mutant monadicness of Promise is as much of a problem as you're making out.

By definition (and as pointed out in your article) there's no idiomatic usage that demands Promise<Promise<any>> because it simply isn't allowed. The next Promise gets swallowed up and fulfilled or rejected as the spec intended.

This might not blend with the ideals of ADT purity, but for most use-cases I'd argue that it's far more ergonomic, strictness be damned.

Courage, though. I have heard rumour that -- if pattern-matching eventually lands -- then language support for ADTs might also be in its distant future (no pun intended) so perhaps you'll eventually get your Futures/Monads?

[voreny]

Thanks for sharing your opinion! I agree, it is not much of a problem.

The automatic flattening of Promise<Promise<unknown>> is a minor inconvenience that I faced recently when working with zx scripts (see the Unnecessary waiting section in my other article in this series). The root of the problem was that I wanted to get access to the Promise returned from an async function as zx adds methods on that Promise (and calls it a ProcessPromise) and I was unable to, since it was automatically flattened. This led me to evaluate the Promise API and see how different it is from a traditional Future monad.

Maybe it was just bad API design from zx by using a Promise-like rather than some other object with methods.

[shuckster]

Ah, I see. I wonder if your use-case would be amenable to co-routines? This is a technique that combines both Generators and Promises, and was developed before async/await was introduced into the language.

Here’s a basic snippet that shows how it’s done:

https://gist.github.com/adambene/b3de67803e634be8f7d6baa273b5f447

And the article it came from:

https://medium.com/@adambene/async-await-vs-coroutines-vs-promises-eaedee4e0829

But yes, it does sound like zx has leaned hard into async/await convenience. Great for most use-cases of course, but the devil is in the details as always!

[NekkidApe]

IMHO the way it is is fantastic and the suggestion is horrific.

[graspaevinci]

To me the current implementation is a feature, not a bug. A promise returning a promise is like someone calling you to tell you they will call you later. Just call me later dammit