[LoganDark]

That's true, Rust has futures and those aren't objects, they're just state machines. However, "awaiting" a future causes it to execute nested inside your own, not as a new task, so it doesn't act as a traditional promise/future. I'm pretty sure GGP was referring to the OOP concept.

Promises in, say, JavaScript, represent the eventual outcome of an asynchronous computation. When you call an asynchronous function, it starts immediately and you get a Promise for it. Asynchronous callers can then await this Promise to give the impression that they're performing a sub-computation, but technically they are just waiting on a new separate task. Futures in, say, Kotlin, are the same thing, and channels are how both of these are typically implemented.

Those kinds of Promises require some bookkeeping that's not free. While it's helpful to be able to just pass around "the eventual outcome of a specific task", that's not actually needed for asynchronous functions to be able to return values. You just need a way for the function to execute nested within another without necessarily requiring a new task.

I've taken a look at OP's library, and it seems to be lower-level than yielding. That means either one of these paradigms can probably be built on top of it. I take back my statement that it's a missing feature, I thought this library was meant to do more than it does.

[dragonwriter]

> That's true, Rust has futures and those aren't objects, they're just state machines. However, "awaiting" a future causes it to execute nested inside your own, not as a new task, so it doesn't act as a traditional promise/future.

That sounds like a lazy future rather than a concurrent one, but both are traditional futures.

> I'm pretty sure GGP was referring to the OOP concept.

Its not really an “OOP concept”. AFAICT, concurrent promises/futures or equivalent constructs mostly appeared in (often relatively obscure) functional-ish and logic languages before the mid-00s, when they started getting implemented in industrially popular, mostly OOP, languages.

[LoganDark]

> Its not really an “OOP concept”.

It sort of is, because what you're doing is encapsulating the concept of "a value that may arrive in the future" with an object. Both Promises (in JS) and Futures (in Kotlin) work this way.

What I'm saying is that you don't necessarily need to encapsulate that. Rust doesn't: Futures may be called "futures", but they're actually more like "suspendable computations" (not to be confused with generators, which have their own proposal, or coroutines, which also have their own proposal). You can await one as part of another suspendable computation, but you're not holding an object that represents a concept (as in a Promise), you're holding the computation itself. By awaiting it, it becomes a part of you.

The only place a Promise/Future is necessary is when you're not using the computation directly: when you chuck a function off to a task scheduler in order for it to be executed for you. Then, in order to get anything back, you need a handle to that eventual return value. There's your Promise/Future. But if you simply don't chuck it off in the first place, and integrate it into your own suspendable computation instead, you don't need any sort of Promise/Future.

I should note that having taken a look at this library myself, it seems like both paradigms should be possible to implement on top.

[dragonwriter]

I don't see how the abstraction of a future or promise is any more inherently object oriented than than the abstraction of a first class function. They each involve a handle for a computation with particular features, and they each are unnecessary when directly embedding the computation rather than passing it around, but a first class value representing a computation is not a fundamentally object-oriented concept.