this post was submitted on 16 Sep 2026
25 points (100.0% liked)

Programming

28725 readers
343 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 3 years ago
MODERATORS
top 5 comments
sorted by: hot top controversial new old
[–] somegeek@programming.dev 2 points 2 weeks ago

This is so awesome and so far beyond my current knowledge!

I'm trying to learn and wrap my head around concurrency in Clojure recently. I only know asynchronous programming in Javascript. The mental model in JS for async itself, isn't very complex. Because it's a single thread. But in Clojure, you also have multiple threads so you can have multi threading and async at the same time.

From what I understand, Clojure has made it super simple, but I still haven't understood it.

[–] TehPers@beehaw.org 2 points 2 weeks ago (1 children)

From the paper:

The most straightforward approach is unaware cancellation, where a task has no opportunity to react to being cancelled. This approach is taken by Rust in both Tokio and Smol. In Rust, cancellation essentially means never executing a coroutine again after it has yielded. With a direct handle on the coroutine, this simply means not polling the coroutine, or explicitly dropping it.

Maybe I'm misunderstanding this, but at least with Tokio, aborting a task causes it to be stopped and dropped at the next await point. Also, in Rust, the conventional way to cancel a future is to drop it.

By dropping the future, you are signaling to it that it has been canceled. A future can respond to this by implementing Drop, which gives it an opportunity to do whatever it wants (usually some kind of cleanup but it can go as far as making blocking database calls if it wants to).

Sure, some other languages work by throwing some kind of exception that bubbles up, or you can check a cancellation token or abort signal or whatever to see if the task is canceled. Using Drop is just another way to accomplish the same thing.

[–] sukhmel@programming.dev 1 points 2 weeks ago

I'm guessing, they mean the user of a future that already exists as it is, what you mean is you can implement a future that would provide a way for the code inside to know of being cancelled. But most of the time you don't do that, and a function that was polled once and then dropped will never know about that

[–] aev_software@programming.dev 0 points 2 weeks ago (1 children)

Personally, I hate awaiting async actions and prefer callbacks. Just execute when done, thanks. I don't care in which order.

[–] epyon22@sh.itjust.works 3 points 2 weeks ago

Same I still prefer promises in JavaScript over async await for this reason.