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

101–110 of 133 posts

Re: Promises are not neutral enough

#101

Post by spion »

matharmin wrote: post #58
spion wrote: post #43

Earlier quoted context omitted.

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 nativ…

Gorgi Kosev's post highlights a very nice use case for generators (database transactions). However, in all my JavaScript over the last few years, that is the only good use case I've found so far in my code base for generators. In all other use cases I've come across, async-await works just fine, and has a much nicer syntax to work with.

I elaborated that case in the most detail, but there are many other problems that generators solve mentioned in the blog post. Another very common one is getting the current user that initiated the request (or maybe their session), which you need to pass around to all your functions/classes.

What if you could simply `yield getCurrentUserSession` and the engine which ran the toplevel generator returned it back to you?

jhusein's compositional functions solved the syntax issue.

Re: Promises are not neutral enough

#102

Post by rmrfrmrf »

You can have your referentially-transparent cake and eat it too, but the main problem is that no one has developed a decent library that marries FantasyLand-compliant wrappers with Promise interop.

There are about 8 million Task/IO monad implementations and no one stopped for a second to think that `task.fork` could just return a Thenable and work with async/await as expected.

Re: Promises are not neutral enough

#103

Post by kazinator »

deathanatos wrote: post #96
kazinator wrote: post #85

The whole idea of cancelation is poor; it shouldn't even be a feature. The way you avoid unnecessary computation, when you have laziness, is to just roll it into the lazy semantics. Have it so that if the promise generates something complicated, like a sequence, that the promise only generates as much of that something as is accessed (and maybe only a little bit beyond that). In other words, the async promises should…

> Have it so that if the promise generates something complicated, like a sequence, that the promise only generates as much of that something as is accessed (and maybe only a little bit beyond that). What about when you start composing Promises? For example, say I have a top-level promise that just returns a value. But under the hood, it needs a promise that generates an array. Even if the under-the-hood promise gener…

In that case, one thing we can do is that the under the hood promise is not forced at all if the wrapping promise's value isn't forced yet. Then we don't have any async behavior, unfortunately; no calculation begins until the promise is called in. We can do part of the calculation ahead of time, but then stop and don't complete it until there is an indication that the value is required. That is fudgy though: how far is far enough to reap the async benefit without the downsides.

How about this alternative: instead of .cancel() on promises have a .commit(). This is called if you're sure that you will eventually need that value. The calculation then proceeds full steam ahead: no going back.

You can ask for the value with or without .commit(); it is just a hint. But if you ask without .commit(), you may have to wait for a completion that was deliberately stalled due to your lack of commitment.

Without .commit(), async promises will still proceed on their own to some extent based on some fudge factor; we don't want programmers automatically calling .commit() on every promise they make to get the async benefit, which defeats the purpose.

Uncommitted promises could be identifiable to the garbage collector and subject to an internal cancelation protocol between GC and the promises. That protocol basically helps the promise's thread vacate the object so it can be reclaimed.

Promises could have some sort of hint about how far to proceed before requiring commitment. This would have to be well thought out: such hints tend to be too system and workload specific. Automatic tuning is better. The promise system could keep some statistics about how soon various kinds of promises are called in after being initiated, and how often they are called in at all, and then uncommitted promises could decide based on that how far to compute.

Re: Promises are not neutral enough

#104

Post by lobster_johnson »

yuchi wrote: post #79
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…

Promises don‘t swallow errors (sorry to be pedantic but there’s no concept of Exception in JS). They just propagate it to the rejection channel. What was your precise experience?

Of course JS has exceptions. The EcmaScript explicitly uses the term "exception" [1].

[1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...

Re: Promises are not neutral enough

#105

Post by rockymadden »

rmrfrmrf wrote: post #102

You can have your referentially-transparent cake and eat it too, but the main problem is that no one has developed a decent library that marries FantasyLand-compliant wrappers with Promise interop. There are about 8 million Task/IO monad implementations and no one stopped for a second to think that `task.fork` could just return a Thenable and work with async/await as expected.

This does exist: https://github.com/fluture-js/Fluture/blob/master/README.md#...

Future.of(0).promise().then(console.log);

Re: Promises are not neutral enough

#106

Post by lobster_johnson »

rmrfrmrf wrote: post #94
amptorn wrote: post #92

Earlier quoted context omitted.

> there’s no concept of Exception in JS Sure there is. What else does the `throw` statement do, if not throw an exception?

`throw` can throw anything. By convention, it throws Error objects.

"throw" takes the value to throw as an exception. An exception is an event which can be handled with "catch". [1] The standard refers to predefined errors such as TypeError as "exceptions".

[1] http://www.ecma-international.org/ecma-262/6.0/#sec-try-stat...

Re: Promises are not neutral enough

#107

Post by amptorn »

rmrfrmrf wrote: post #94
amptorn wrote: post #92

Earlier quoted context omitted.

> there’s no concept of Exception in JS Sure there is. What else does the `throw` statement do, if not throw an exception?

`throw` can throw anything. By convention, it throws Error objects.

Sure, but "exception" is the programming term for that kind of behaviour. Saying "JavaScript has exceptions" doesn't imply that JavaScript has a global builtin object named `Exception` any more than saying "JavaScript has loops" implies that there's a global builtin object named `Loop` or `For`.

Re: Promises are not neutral enough

#108

Post by fefb »

I rarely use promises. Just for the most simplest logics. When a package return promises in its API, I just use Rx.Observable.fromPromise(theRomise) . ReactiveX, especially RxJS, is so powerful to handle async events, from differents sources to differents logics. You can build powerful pipelines with it.

Re: Promises are not neutral enough

#109

Post by mathgladiator »

spion wrote: post #97
fiatjaf wrote: post #63

Earlier quoted context omitted.

MobX is horribly opinionated, a monstruous abstraction of spaghetti, and you're saying Promises limit it?

MobX is the most powerful front end development library on the market right now. It single-handedly solves the cache invalidation problem in a performant way, and its pluggable into any framework. And yes, promises limit it.

How does one measure power? What market?
Post reply on HN