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 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.
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.
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.
> Promise itself has no first-class protocol for cancellation, but you may be able to directly cancel the underlying asynchronous operation, typically using AbortController.
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!)
I personally find it to be perfectly readable. I've heard of people with issues with white text on a black background, but I don't fully understand it. Do you have astigmatism?
> Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers.
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.
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.
It is a specialised instrument but a useful one: batch processing and query pagination are first class use cases for generators that can really simplify business logic code. Stream processing is another and in fact Node.js streams have had a generator API for several releases now.
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.
If I know the javascript ecosystem, and I think I do, this is an opportunity for some undergrad from Kazakhstan to create a library called 'Pinky' that offers unbreakable promises, which will have 1M downloads on npm and 10K stars on github, and will allow the dev to get a US Visa and employment.
The library will get additional maintainers until it balloons into 100Kloc with features like reading config files, which would need to eventually get split into a transitive dependency called configy, until one day a maintainer clicks on an enlarge penis link or gets phished by a fake AI girlfriend that was actually a russian dude, and it hits half of the javascript ecosystem because it had become a transitive dependency for every single package, and then everyone switches to a new package manager that somehow survived this due to a security feature, (but it was actually because no one uses that package manager and so the attacker didn't target it) also it's faster and used by the top startups of YC so it's very sexy and it can now be your girlfriend so you don't need a fake AI girlfriend and devs don't get supply chained anymore.
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 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.
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.
TC39 seems to be failing at many things for the past 10 years.
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.
I was certainly surprised to see it when I found it.
C# has very good support for this.
You can even link cancellation tokens together and have different cancellation "roots".
> Promise itself has no first-class protocol for cancellation, but you may be able to directly cancel the underlying asynchronous operation, typically using AbortController.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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!)
GC can be very slow. Relying on it for control flow is a bold move
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.
and so the thirty year old hackathon continues...
Off topic, but that site has really nice design
Mh, I couldn't read due to the huge contrast and had to switch to reader mode, so...
I personally find it to be perfectly readable. I've heard of people with issues with white text on a black background, but I don't fully understand it. Do you have astigmatism?
I mean, I'm not a designer but it was interesting enough to call out.
You can also race it with another promise, which e.g. resolves on timeout.
> Libraries like Effect have increased the popularity of generators, but it's still an unusual syntax for the vast majority of JavaScript developers.
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.
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.
It is a specialised instrument but a useful one: batch processing and query pagination are first class use cases for generators that can really simplify business logic code. Stream processing is another and in fact Node.js streams have had a generator API for several releases now.
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.
If I know the javascript ecosystem, and I think I do, this is an opportunity for some undergrad from Kazakhstan to create a library called 'Pinky' that offers unbreakable promises, which will have 1M downloads on npm and 10K stars on github, and will allow the dev to get a US Visa and employment.
The library will get additional maintainers until it balloons into 100Kloc with features like reading config files, which would need to eventually get split into a transitive dependency called configy, until one day a maintainer clicks on an enlarge penis link or gets phished by a fake AI girlfriend that was actually a russian dude, and it hits half of the javascript ecosystem because it had become a transitive dependency for every single package, and then everyone switches to a new package manager that somehow survived this due to a security feature, (but it was actually because no one uses that package manager and so the attacker didn't target it) also it's faster and used by the top startups of YC so it's very sexy and it can now be your girlfriend so you don't need a fake AI girlfriend and devs don't get supply chained anymore.