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

71–80 of 133 posts

Re: Promises are not neutral enough

#71

Post by fiatjaf »

twohearted wrote: post #27

The analogies damage this article because they feel wrong. For example the "never synchronous" example is more like this: You order a burger at the cashier window, then go to the pickup window. If the burger is already made, it's already at the pickup window when you get there. The author wants a special case where if the burger is already made, they hand it to you immediately at the cashier window. This might seem m…

Actually, the analogies help prove the wrongness of the underlying point, as you noted.

Re: Promises are not neutral enough

#72

Post by z3t4 »

matharmin wrote: post #57

I work with fairly large JavaScript codebases, and the issues mentioned in the post has never been an issue for me. The switch from callbacks to Promises, and later to async-await has made a massive improvement to the ease of writing, reading and maintaining the code. Lazy and cancellable tasks are edge-cases that don't need support in Promises directly. I haven't needed either of those in more than a couple of place…

I think Promises=>async/await works great for certain domains like get a value from a database, them make an insert, then do something else and then return a message to the user.

I however write a lot of systems where almost all operations need to be concurrent, cancelable and rate-limited.

Personally I find callbacks and the event loop easy to reason about, but too daunting when all you do is CRUD requests to a database.

The problem with Promises though is that they spread, they don't like to live side by side with other async paradigms.

Re: Promises are not neutral enough

#75

Post by z3t4 »

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…

I had the same experience with the callback pattern. It literally took a whole year to grok. And I code almost every day. I'm now a ninja with callbacks. So it's a hard to motivate myself to learn Promises. Syncronious code is more easy to deal with, and you get concurrency by thread abstraction. But it will eventually bite you when you start to get double transactions eg line 1 checks if there's funds in the account, line two draws money, line 3 inserts good. But then another thread takes the money between line 1 and 2. And then the "single threaded" event loop actually becomes easier to deal with then making sure your code is "thread safe" with locks etc.

Re: Promises are not neutral enough

#76

Post by paroneayea »

One of the big challenges mentioned with promises is that you have to kind of commit to promises linking to promises... this is a common problem with async systems added later, where you have to "line them up like gears", and you can't just do async functions which call non-async functions which call async functions and expect it to work. Python has this problem too.

There's a solution in delimited continuations, however delimited continuations seem to only be used and understood in the Scheme community (are they used anywhere else?). Delimited continuations allow you to suspend your code to a "prompt" lower in the stack at that point... and it doesn't matter if you have non-"async" code in between.

It'll be nice when they make their way to other more mainstream languages.

Re: Promises are not neutral enough

#77

Post by codedokode »

fiatjaf wrote: post #69
codedokode wrote: post #28

Earlier quoted context omitted.

> otherwise there's no well defined place in your program for the exception to go. I don't see the problem with that. Unhandled exceptions can occur at any place of your program. I also don't see why the unhandled exception from the background thread cannot terminate main thread. Why not? That is how unhandled exceptions are supposed to work. Terminating the program is the optimal default behaviour for any error in m…

In Go there are two ways you can handle wrong things happening: - return an error - panic What is the recommended, best, pretty, beautiful way? Return an error. Nobody uses panic. Javascript Promises are equivalent to that. If you want to stop the main program, call process.exit(). That would be the equivalent of panic.

I don't think it is beautiful. This fills program with lots of unnecessary `if`s for checking results of each call. Also, it prevents one from chaining functions like a(b(x)).

Re: Promises are not neutral enough

#78

Post by yuchi »

matharmin wrote: post #57

I work with fairly large JavaScript codebases, and the issues mentioned in the post has never been an issue for me. The switch from callbacks to Promises, and later to async-await has made a massive improvement to the ease of writing, reading and maintaining the code. Lazy and cancellable tasks are edge-cases that don't need support in Promises directly. I haven't needed either of those in more than a couple of place…

100% agree.

In my (more or less extensive) experience missing cancellation is what bites you more. Not because Promises don‘t implement it (I worked a lot with bluebirds CancellablePromises a lot and… it’s not fun) but because there’s no unified, “standard” and “specced” way.

AbortControllers (which are just abort tokens hidden as EventEmitters) are not that bad but we’ll have to wait a lot before all fetch implementation support it (I’m looking at you V8 and Safari!). I still don‘t understand why they didn’t called it CancelController since “abort” is such an overlodaded term.

Also (still in my experience) cancellation is incredibly more complex than it could seem. You don‘t want to simply stop the synchronous propagation, you want to act on it! You resources to be freed, you want partially completed async process to rollback what has already been done. Not easy.

Re: Promises are not neutral enough

#79

Post by yuchi »

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?

Re: Promises are not neutral enough

#80

Post by yuchi »

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

Post reply on HN