In a pekko Java project I'm working on, I've been creating a Task class whose abstraction looks something like:

public abstract class Task<T> {
    public static <T> Task<T> of(Supplier<T> fn) {}
    public static <T> Task<T> connect(Source<A, ? extends KillSwitch> source, Sink<A,CompletionStage<T>> sink) {}
    /* ... */
    public abstract TaskControl<T> run(Materializer mat);
}
public class TaskControl<T> {
    public void cancel() { /* ... */ }
    public CompletableFuture<T> future() { /* ... */ }
}

Task is a description of running something, but also has a unified cancellation API (across futures and connected RunnableGraphs). It is inspired heavily from ZIO's API. A lot of combinators are written.

Would this be an interesting abstraction to have in Pekko itself? The fact that streams need to be materialized brings them close to a Task monad already, and in my experience having a unified API between running streams and futures is very valuable.

We'd of course add a nice Scala API as well (which should be trivial).