Why does async not use the existing terms Promise or Future?

[hibachrach]

As best I can tell, Async::Tasks are functionally the same as promises and/or futures in other languages. And indeed, on Wikipedia, the article on the subject is called "Futures and promises". The word "async" already has a loaded meaning in other languages to do an implicit wrapping of a promise on the return value of a function/method.

Or am I missing a fundamental difference between Async::Tasks and futures/promises?

[ioquatix]

You are correct, the terminology is overloaded and in many cases, generally, over-complicated.

I talked to this in some of my presentations. Having a clear understanding of "concurrency" vs "parallelism" is important.

"Async" means "not existing or occurring at the same time" - the opposite of synchronous. I like to think of it as "code without (the consideration of actual) time". In my mind, "concurrent" (interleaved) execution and "parallel" (simultaneous) execution are both forms of asynchronous execution. The opposite is code which always executes with synchronisation between each step - i.e. synchronous execution. This is probably why we have "synchronisation primitives" which bring order to otherwise unpredictable asynchronous execution models.

Most code is a combination of asynchronous and synchronous execution (Amdahl's law is a good context for this). It's common to use async as a point where concurrency can be introduced and await as a point where concurrent execution is joined.

A Promise or Future is a mechanism for synchronising asynchronous work. They are often used for implementing map/reduce style patterns. Other primitives include conditions, queues, barriers, etc.

More specifically, a Promise or Future interface usually provides two things: a mechanism for waiting and a mechanism for signalling - usually either a result or an error is common.

Async::Task provides both these things, but it also encapsulates the fiber which generates the result or error. Therefore, it is a more elaborate construct and I wouldn't really consider it a primitive. In essence, Async::Condition is the primitive that implements the Promise-like interface, and is used by Async::Task to provide a mechanism to wait on the completion of the task.

However, this is not strictly necessary - there are many ways a concurrent task could indicate completion - a queue could also be used. As such, the Ruby Fiber.scheduler does not impose any such interface on Fiber.schedule - i.e. there is no Fiber#wait - and you might want to create an implementation of Fiber::Promise in that case if you desire such a synchronisation primitive.

[hibachrach]

Thank you for the wonderful answer!

there are many ways a concurrent task could indicate completion - a queue could also be used

I'm not quite sure what you mean by this--is this employed in some other lang/runtime so I could investigate to what you're referring?

[ioquatix]

I don't think there are any direct implementations I can point you at, but a queue can be used for completions, e.g.

queue = Thread::Queue.new

10.times do
  Fiber.schedule do
    queue << work
  end
end

Fiber.schedule do
  queue.each do |result| # wait for the work to be completed
    puts result # do something with result
  end
end