+1. In general, this fits nicely into our nomenclature: A Task is the result of submitting something to a distributed task scheduler. Its result is calculated from a task graph.

We can still call it a Future-like akin to asyncio.Task to keep the reference for developers.

I actually don't have a very strong opinion here. I'm mildly concerned about confusion internally and about migration efforts (for users). If we believe this is worth it, I'm fine with it.

If we choose to rename Futures we might also want to reconsider renaming or aliasing submit as well. In the context of tasks, it is often talked about creating a task asyncio, for instance, uses asyncio.create_task

I don't think that we should rely on asyncio as a model of intuitive behavior 🙂

My mental model of a naive user finds "submitting a task" and "creating a task" to be similar in terms of complexity. My gut reaction is to leave submit alone for now.

I'm mildly concerned about confusion internally and about migration efforts (for users).

My sense is that we can probably leave aliases here for a long time.

cc @jacobtomlinson and @jrbourbeau for when he gets back

Yeah I like this idea. I spend a lot of time thinking about tasks in an async context and I think Dask could totally adopt the same thing. While I agree we shouldn't use asyncio as a model of intuitive behaviour I do think async programming in general has some common terminology that we could use. I like the call_soon method from trio/anyio's task groups too.

I think being able to talk about the "Tasks API" rather than the "Futures API" will be more accessible to new users when teaching too.

@fjetter is this something that someone on your team can do, maybe early in 2024?

Alternatively @jacobtomlinson maybe this is something that people in NVIDIA want to help with? It seems like a pretty accessible task.