Hacker News

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 service promises on what happens if you cancel a promise, unless you as a dev take care to offer some.

It's also obvious that some operations are not necessarily designed to be cancellable - imagine a 'delete user' request - you cancelled it, now do you still have a user? Maybe, maybe you have some cruft lying around.

But still, other than the obvious wrong solution - C# had a Thread.Abort() similar to the stop() function that you mentioned, that was basically excommunicated from .NET more then a decade ago, I'm still not happy with the right one.

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.

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.

> "Cooperative" (as opposed to preemptive) cancel is much cleaner.

Which what Thread.interrupt does.

C# has very good support for this.

You can even link cancellation tokens together and have different cancellation "roots".

I don't think the control flow relies on GC.

The control flow stops because statements after `await new Promise(() => {});` will never run.

GC is only relied upon to not create a memory leak, but you could argue it's the same for all other objects.

as long as there's no leak interrupting a promise should be good for performance overall, not necessarily for the front-end but for the whole chain.

Not that very slow for web applications. Maybe for real time or time-sensitive applications. For most day to day web apps GC pauses are mostly unnoticeable, unless you are doing something very wrong

This is addressed at the end of the article:

  The catch

  You're relying on garbage collection, which is nondeterministic. You don't get to know when the suspended function is collected. For our use case, that's fine. We only need to know that it will be collected, and modern engines are reliable about that.

  The real footgun is reference chains. If anything holds a reference to the hanging promise or the suspended function's closure, the garbage collector can't touch it. The pattern only works when you intentionally sever all references.

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 generator, they're nice to have, but it's mostly a "library author" tool, and even in that scope it's usage just isn't warranted all that often.

Generators peaked in redux- saga and thunk days before we had widespread support for async/await.

You're right, mostly pointless syntax (along with Promise) now that we can await an async function anyway, especially now with for .. of to work with Array methods like .map

But there are still some use cases for it, like with Promise. Like for example, making custom iterators/procedures or a custom delay function (sync) where you want to block execution.

Mh, I couldn't read due to the huge contrast and had to switch to reader mode, so...

You can but it still won't get cancelled. I found out when I tried to implement a hard time limit to a call.

> If I know the javascript ecosystem, and I think I do

You think you do, but...