Why no .map() ?

[aboisvert]

I've started using gears here and there, and it's pretty good. I like it :)

One thing that comes up often is I'd like to be able to either .map() or .flatMap() a Future, since it's often the most idiomatic. It's basically the sequential composition, either in the domain of pure values, or sequencing Futures.

Is there a reason .map() and .flatMap() aren't provided on Future? I understand gears wants to promote direct-style, and I love that. But I wouldn't want dogmatism to stand in the way of pragmatism.

I know I can work around using .await and creating another Future but it feels a lot more clumsy.

Inquiring minds want to know.... Thanks!

[bishabosha]

if they were introduced it should probably be on Task which is referentially transparent (Task.this.start converts it to a Future)

[PavanKumar8125]

yes

[natsukagami]

Hi! Thanks for trying out gears!

The lack of .map and .flatMap on Futures are intentional. As Jamie mentioned above Futures are not value containers, they represent actively running branched concurrency (most of the time), therefore having value transformers don't really make sense, especially when you can always .await a Future that you create. Furthermore, every time a runnable Future is created its lifetime is tied to the enclosing Spawn scope; .map will make this relationship blurry (there's a reason there's only very limited ways to create a runnable Future in gears, and how the types make it difficult to write your own functions returning dangling Futures - we want to emphasize the responsibility that comes with the great power). This is the more "theoretical" reason.

The more pragmatic reason is that creating Futures are not on the same order of magnitude in performance as simply creating an immutable mapped container. While both virtual threads and Scala Native delimited continuations are pretty fast for small functions, creating them on whims will put strain on the scheduler and GC that's hard to track down (this happens even for Scala 2 futures and even in other languages!). A .map being bundled in the library makes users "follow the path of least resistance" sacrificing performance, even though (I believe) using direct .await will not be an ergonomics/performance trade off.

That said, I really welcome some examples where having .map / .flatMap is an obvious improvement over direct style! It will definitely help us take into account when evolving gears.

(Also see Source, we had a .map method for it before; but it was easy to misuse, causing unexpected slowdowns. We ended up changing the method name to .transformValuesWith, so that it is there if you know what you're doing)

[aboisvert]

Thank you very much for the explanation. I guess I must be so used to the traditional Futures/Promises ... I didn't stop long enough to think this through :)

The "symptom" I had in my code is returning Futures from functions. I guess that's not as common a practice with gears... which is a good thing since it avoids the 'function coloring' issue. I've gotten so used to the coding style where if you're doing something possibly blocking, you wrap it in a Future (or an IO/ZIO/...) right away.

This is a good reminder for me that Gears makes the assumption that the runtime itself can effectively manage blocking operations (e.g., with fibers or similar) and therefore Futures and .await calls are only used at the point where you want to explicitly model asynchronous execution.

Hopefully this is a correct portrayal. Feel free to comment/explain further if I got anything wrong!

[natsukagami]

Yep, you got it absolutely correct! We definitely want people to just write def f(...)(using Async): T rather than returning Futures, since it would relieve you both from managing the lifetime of the future (e.g. when should it abort?), and at the same time allow your caller to decide the concurrency.

.await calls are only used at the point where you want to explicitly model asynchronous execution.

Exactly!