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

You can't cancel a JavaScript promise (except sometimes you can)

inngest.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: You can't cancel a JavaScript promise (except sometimes you can)

#51

Post by cowboyd »

no_wizard wrote: post #30
horsawlarway wrote: post #12

Earlier quoted context omitted.

There just aren't that many spots where the average js dev actually needs to touch a generator. I don't really see generators ever crossing into mainstream usage in the same way as the other features you've compared them to. Most times... you just don't need them. The other language tools solve the problem in a more widely accessible manner. In the (very limited & niche) subset of spots you do actually need a generat…

mainly because they messed up on implementation, in two ways. This is of course my opinion. The first being `.next()` on the returned iterators. If you pass an argument to it, the behavior is funky. The first time it runs, it actually doesn't capture the argument, and then you can capture the argument by assigning `yield` to a variable, and do whatever, but its really clunky from an ergonomic perspective. Which means…

I think writing an effect library yourself is a tough ask, but some of them have gotten really, really good. And they get you things that are simply not possible with promise. Check out Effection if you want a more vanilla javascript syntax, or Effect if you're really into expressing things functionally.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#52

Post by runarberg »

notnullorvoid wrote: post #46
runarberg wrote: post #16

Earlier quoted context omitted.

TC39 seems to be failing at many things for the past 10 years.

Hard disagree, TC39 has done great work over the last 10 years. To name a few: - Async/await - Rest/spread - Async iterators - WeakRefs - Explicit Resource Management - Temporal It's decisions are much more well thought out than WHATWG standards. AbortSignal extending from EventTarget was a terrible call.

many things !== all the things

More good works from the last 10 years includes .at(), nullish chaining, BigInt etc.

But most of what you mentioned is closing in on 10 years in the standard (Async/Await is from 2017) meaning the bulk of the work done is from over 10 years ago.

The failure of AbortSignal is exactly the kind of failure TC39 has been doing in bulk lately. I have been following the proposal to add Observables to the language, which is a stage 1 proposal (and has been for over 10 years!!!). There were talks 5 years ago (!) to align the API with AbortSignal[1] which I think really exemplifies the inability for TC39 to reach a workable decision (at least as it operates now).

Another example I like to bring up are the failure of the pipeline operator[2], which was advanced to stage-2 four years ago and has been in hiatus ever since with very little work to show for it. After years of deliberation very controversal version of the operator with a massive community backlash. Before they advanced it it was one of the more popular proposals, now, not so much, and personally I sense any enthusiasm for this feature has pretty much vanished. In other words I think they took half a decade to make the obviously wrong decision, and have since given up.

From the failure of the pipeline operator followed a bunch of half-measures such as array grouping, and iterator helpers etc. which could have easily been implemented in userland libraries if the more functional version of the pipeline operator would have advanced.

1: https://github.com/tc39/proposal-observable/issues/209

2: https://github.com/tc39/proposal-pipeline-operator

Re: You can't cancel a JavaScript promise (except sometimes you can)

#53

Post by estimator7292 »

torginus wrote: post #36
pjc50 wrote: post #6

I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…

I don't like it - you're forced to pass around this token, constantly manage the lifecycle of cancellation sources - and incredibly bug prone thing in async context, and it quickly gets very confusing when you have multiple tokens/sources. I understand why they did it - a promise essentially is just some code, and a callback that will be triggered by someone at some point in time - you obviously get no quality of ser…

Cancelling a token doesn't immediately abort the underlying Task. It is up to the implementation of that task to poll the token and actively decide when to abort.

In your example, you'd design your delete task such that if you want it to be cancelable, it can only be canceled before data is modified. You simply don't abort in the middle of a database transaction.

Moreover, because of the way cancellation tokens work, you can't abort blocking function calls unless you also pass the token along. There just isn't a mechanism that can interrupt a long IO operation or whatever unless you explicitly go to the effort to make that happen.

A cancellation token is more of a "pretty please stop what you're doing when you feel like it" concept than Thread.Abort().

Re: You can't cancel a JavaScript promise (except sometimes you can)

#54

Post by estimator7292 »

CharlieDigital wrote: post #40
torginus wrote: post #36

Earlier quoted context omitted.

I don't like it - you're forced to pass around this token, constantly manage the lifecycle of cancellation sources - and incredibly bug prone thing in async context, and it quickly gets very confusing when you have multiple tokens/sources. I understand why they did it - a promise essentially is just some code, and a callback that will be triggered by someone at some point in time - you obviously get no quality of ser…

> ...constantly manage the lifecycle of cancellation sources Very rare unless you are spawning your own. Usually, you are passing through a runtime provided token (e.g. ASP.NET).

Not rare in the slightest. C# is used in a lot of places that aren't the web and don't have extra frameworks piled on.

If you're writing a bare C# library for desktop deployment, you're managing your own cancellation sources.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#55

Post by runarberg »

fragmede wrote: post #47
shadowgovt wrote: post #37

I soft of feel like every five years someone comes along and tries to re-invent cancellable threads and immediately arrives back at the same conclusion: the problem of what it means to "cancel" a thread is so domain-specific that you never save anything trying to "support" it in your threading framework; you try and save people the effort of doing something ad-hoc to simulate cancellation and build something at least…

But what if we add another layer of indirection.

The fundamental theorem of software engineering.

https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...

Re: You can't cancel a JavaScript promise (except sometimes you can)

#56

Post by stevefan1999 »

I would also argue that Rust failed to cancel a Future too, considering I came from a C++ and C# background where I know a lot more about async/await and the missing of "cancellation token" in Tokio is so infuriating.

I have to came all the way to attach it to a Future, that because Rust doesn't have any default argument, I mean I have to supply cancellation token from the top to bottom.

But in hindsight, Golang's context actually do mimick cancellation token in some sort, but in a way that the cancellation is cascaded and recursive by using done in canceler or deadline which means it is timing and latency sensitive.

If you truly want cancellation token style, you need to use semaphores or by explicitly polling the cancellation channel (which is what you can do with context) which can hurt if you don't have enough thread slack.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#57

Post by esprehn »

bakkoting wrote: post #50
esprehn wrote: post #14

Earlier quoted context omitted.

AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.

Browsers have said that they are unwilling to ship any new cancelation mechanisms given that AbortSignal already exists, so we can't ship a different CancelToken. But I think there's a path to standardizing a subset of the existing AbortSignal machinery [1]. (I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of commi…

Yes, I was around during the original discussions. AbortSignal exists because TC39 was taking too long and cancelling fetch() is table stakes for a networking oriented platform like the web.

Those threads are a good example of what's wrong in TC39. A simple AbortSignal could have been added, but by the time it's reconciled with SES, large speculative APIs like Governers, or the original attempt to add a parallel throw mechanism just for cancellation, nothing actually gets done.

It's been 10 years since CancelToken was first discussed and we're still debating it.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#58

Post by watermelon0 »

esprehn wrote: post #14
pjc50 wrote: post #6

I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…

AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.

Unless I'm missing something, AbortSignal is quite standardized on backend as well.

Of course not all libraries support it, but many do, and support seems to be growing.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#59

Post by DonHopkins »

AtlasBarfed wrote: post #42
teraflop wrote: post #18

Earlier quoted context omitted.

I am surprised that you had to go out of your way to remove Thread.stop from existing Java code. It's been deprecated since 1998, and the javadoc page explains pretty clearly why it's inherently unsafe. It's hard to miss all the warnings unless you're literally just looking at the method name and nothing else.

One of Java's the ecosystem fundamental platforms is that it's multi-threading. It's gone through too many models. And since Java has a metric ton of blog posts from the 2000s and 2010s, a lot of search engines lead you to older models.java itself has gone from green threads to OS threads and back to green threads now.

Write one, stop anywhere.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#60

Post by phendrenad2 »

mohsen1 wrote: post #15

Back in 2012 I was working on a Windows 8 app. Promises were really only useful on the Windows ecosystem since browser support was close to non existent. I googled "how to cancel a promise" and the first results were Christian blogs about how you can't cancel a promise to god etc. Things haven't changes so much since, still impossible to cancel a promise (I know AbortSignal exists!)

Microsoft supports something god doesn't? That can't be right.
Post reply on HN