3 ms·

Rust has a similar problem, where any future can be dropped at any time in async code, effectively cancelling the future. This means all async code has to be re

Rust has a similar problem, where any future can be dropped at any time in async code, effectively cancelling the future. This means all async code has to be ready to be unexpectedly cancelled at any await point, and implement any defensive cleanup code, etc Some more discussion of the problems this creates in Rust: https://without.boats/blog/asynchronous-clean-up/ https://without.boats/blog/asynchronous-clean-up/

demurgos 2y ago
It's definitely an issue, but it's also an improvement to the situation in other languages as the await points were cancellation is possible are visible in the code. One solution would be linear types that can't be dropped, but interactions with generics and panics make it hard.
pkolaczk 2y ago
If a future is canceled it will run its destructors, so cleanup will usually happen correctly even if the developer didn’t think about it. Connections and files will be closed, memory released, locks unlocked. There are exceptions to that of course, bacause not running something to completion may break business logic - but no language can protect from those kinds of errors. And cancellation can happen only in await points which makes it much easier to analyze than being interrupted at any place like in Java.
jupp0r 2y ago
This is not a bug, it's a feature. You have the ability to handle errors at defined points. As reality is such that errors can happen at any of these points, being able to gracefully handle them is as good as it gets. If you want to compose error handling along the type-of-error axis or the await-point-axis, the language already provides tools for you to do so. Again, not being able to blatantly ignore these errors is a feature, not a bug. In NodeJS/Browser environments, you have the exact same behavior where promises you are awaiting can get rejected.

demurgos 2y ago

It's definitely an issue, but it's also an improvement to the situation in other languages as the await points were cancellation is possible are visible in the code. One solution would be linear types that can't be dropped, but interactions with generics and panics make it hard.

pkolaczk 2y ago

If a future is canceled it will run its destructors, so cleanup will usually happen correctly even if the developer didn’t think about it. Connections and files will be closed, memory released, locks unlocked. There are exceptions to that of course, bacause not running something to completion may break business logic - but no language can protect from those kinds of errors. And cancellation can happen only in await points which makes it much easier to analyze than being interrupted at any place like in Java.

jupp0r 2y ago

This is not a bug, it's a feature. You have the ability to handle errors at defined points. As reality is such that errors can happen at any of these points, being able to gracefully handle them is as good as it gets. If you want to compose error handling along the type-of-error axis or the await-point-axis, the language already provides tools for you to do so. Again, not being able to blatantly ignore these errors is a feature, not a bug. In NodeJS/Browser environments, you have the exact same behavior where promises you are awaiting can get rejected.