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

91–100 of 133 posts

Re: Promises are not neutral enough

#91

Post by amptorn »

naasking wrote: post #81
woah wrote: post #65

Earlier quoted context omitted.

I have to agree. This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics (hint: the author's own library wins this contest). It doesn't consider what programmers use them for. Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors. The author's "improvements" would ruin this. I…

> This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics Or you could consider the possibility that they aren't arbitrary at all. Perhaps these properties are well motivated by, for instance equational reasoning, which is a cornerstone of extensible and maintainable programming. > Promises are meant to semantically (and with async/await, syntactically) resemble a function cal…

> equational reasoning, which is a cornerstone of extensible and maintainable programming

What are the other cornerstones?

Re: Promises are not neutral enough

#92

Post by amptorn »

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?

> there’s no concept of Exception in JS

Sure there is. What else does the `throw` statement do, if not throw an exception?

Re: Promises are not neutral enough

#94

Post by rmrfrmrf »

amptorn wrote: post #92
yuchi wrote: post #79

Earlier quoted context omitted.

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?

> 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.

Re: Promises are not neutral enough

#95

Post by rmrfrmrf »

mstade wrote: post #87
yuchi wrote: post #79

Earlier quoted context omitted.

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?

If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best. In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning a…

This was a problem before native Promises, but not so much anymore.

Throwing on unhandledRejection has been the default in Node.js >= 7 and browsers now have DOM Levels 1 and 3 events for unhandledrejection.

Re: Promises are not neutral enough

#96

Post by deathanatos »

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 generates the array piece by piece, the caller of the larger promise is only even going to get a single value, so they lose the ability to "stop".

(You might imagine that the composed-over promises are network I/O, for example.)

Re: Promises are not neutral enough

#97

Post by spion »

fiatjaf wrote: post #63
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…

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.

Re: Promises are not neutral enough

#98

Post by rmrfrmrf »

codedokode wrote: post #18
saurik wrote: post #7

Earlier quoted context omitted.

One nice thing about "new Promise()" calling the function immediately is that if you are prepared to provide the value immediately then you don't have to return into the runloop, but probably the reason I'd give for why delaying the call would be a horrible idea is that the vast majority of the time the promise is going to do some minimal amount of setup work and then... return to the runloop (and if it isn't, I am g…

No, you won't get the result immediately anyway because then() callbacks are called only on next event loop iteration. This protects from overflowing the stack, but might have small impact on performance.

This isn't correct for native Promises. Native Promises flatten themselves out at the end of each tick and will do any synchronous work possible before either the Promise settles or there's something that needs to get thrown to the event queue.

This all happens synchronously, although deferred, but still can block the app completely if someone is simply wrapping synchronous actions in Promises expecting them to be "async".

Re: Promises are not neutral enough

#99

Post by marcosdumay »

ryandvm wrote: post #40
IIIIIIIIIIIIIII wrote: post #5

This may get me in hot water here but... I started working with JS promises specifically when they were barely available in a beta runtime. It took me over a year of working with them to really get a feel for them, now it's been far longer. That's because while you can "understand" the description and use it just fine, but a deeper comprehension and intuition takes much more time. I experimented a lot and insisted on…

> It took me over a year of working with them to really get a feel for them I had a similar experience. It took quite a while for me to stop shooting my foot. My takeaway from that experience was that, while they do have certain advantages, Promises suck. Any abstraction that is so unintuitive that it takes beginners dozens or hundreds of hours to master is probably not an abstraction worth using - especially if it i…

> Any abstraction that is so unintuitive that it takes beginners dozens or hundreds of hours to master is probably not an abstraction worth using

Javascript can not depend on anything like that, because it's a gatekeeper language. But that is too general a phrasing.

Re: Promises are not neutral enough

#100

Post by rmrfrmrf »

yuchi wrote: post #80
fwip wrote: post #32

It sounds like the author wants coroutines, not promises.

Exactly. I’ve been using redux-saga a lot recently and they really fill the gap between the concept of a long running Task and asynchronous values/executions (Promises).

I just got there myself after thinking async/await would be all I needed.

There's still a lot that can be done with generators, so I don't see them falling out of favor completely yet.

Post reply on HN