You can't cancel a JavaScript promise (except sometimes you can)
inngest.com
inngest.com
Edit: note that there is a "wrong" way to do this as well. The Java thread library provides a stop() function. But since that's exogenous, it doesn't necessarily get cleaned up properly. We had to have an effort to purge it from our codebase after discovering that stopping a thread while GRPC was in progress broke all future GRPC calls from all threads, presumably due to some shared data structure being left inconsistent. "Cooperative" (as opposed to preemptive) cancel is much cleaner.
You can even link cancellation tokens together and have different cancellation "roots".
It's decisions are much more well thought out than WHATWG standards. AbortSignal extending from EventTarget was a terrible call.
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.
(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 committee.)
[1] https://github.com/tc39/proposal-concurrency-control/issues/...
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.
Of course not all libraries support it, but many do, and support seems to be growing.
It's hard to miss all the warnings unless you're literally just looking at the method name and nothing else.
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.
Which what Thread.interrupt does.
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.
> ...constantly manage the lifecycle of cancellation sources
Usually, you are passing through a runtime provided token (e.g. ASP.NET).
Oh and oone more thing - the very (developer-managed) complexity makes it that people constantly got it wrong, usually just enough (as often with the case of threading) that it worked fine 90% of the time, and was very hard to make a case to management why we should invest effort into fixing it.
If you're writing a bare C# library for desktop deployment, you're managing your own cancellation sources.
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().
Before the removal of the GIL in recent years, Python seemed well-positioned to leverage the GIL to offer safe thread-cancellation points that didn’t leave interpreter internals in a corrupted state.
That’s not necessarily an endorsement of the idea of Thread.stop in many cases, since stopped user code can cause broken assumptions at a high level no matter what, but it has its uses. Erlang’s exit/2 is proof of that, though it is a very sharp and rarely-appropriate tool.
I really hope that coroutines land in Rust after being experimental to improve the async stuff.
The C# Tasks are not bad but I think the API could be easier and more precise/clear.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
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.
I unsubscribed at some point because I wasn't working with JavaScript this much, but it's disappointing to see that this work has gone nowhere in the meantime.
I like how Rust futures are canceled by dropping them, even though it's also a footgun (though IMHO this is more of a problem with the select! pattern than with drop-to-cancel proper).
To me that sounds like dropping the task on the floor. Specifically, this will not invoke any finally {} blocks:
More correctly, you should invoke `return()` on the generator. Otherwise, you won't provide execution guarantees. This is how Effection does it. There is no equivalent in async functions, so it sounds like the same problem would apply to the GC technique.
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.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.
I'm getting so tired of hearing this. I loved the article and it's interesting stuff, but how many more decades until people accept generators as a primitive??
used to hear the same thing about trailing commas, destructuring, classes (instead of iife), and so many more. yet. generators still haven't crossed over the magic barrier for some reason.
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.
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.
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 using it to control side effects is clunky.
The second one how it is not a first class alternative to Promise. Async Generators are not the most ergonomic thing in the world to deal with, as you have the issues above plus you have to await everything. Which I understand why, but because generators can't be used in stead of Promises, you get these clunky use cases for using them.
They're really only useful as a result, for creating custom iterator patterns or for a form of 'infinite stream' returns. Beyond that, they're just not all that great, and it often takes combining a couple generators to really get anything useful out of them.
Thats been my experience, and I've tried to adopt generators extensively a few times in some libraries, where I felt the pattern would have been a good fit but it simply didn't turn out most of the time.