Комментарии 7
Имхо, не стоит его переводить. Википедия предлагает несколько переводов, которые где-то используются, но кажется, в реальной жизни они не используются. Терминал попался такой, который переводится плохо (переводы либо длинные, либо звучат тупо), поэтому везде устоялась калька «фьюче» и её более обрусевшие варианты типа «футуры», «фьючеры», «фьючерсы» (это ещё и с экономикой пересекается), можно выбирать любой.
P. S. В C++11 на стадии разработки предлагались типы std::shared_future и std::atomic_future. Вот не хотел бы я поледний переводить.
Мы обсуждали перевод этого термина в канале на gitter российского сообщества Rust и пришли примерно к таким же выводам. Надеюсь текст не режет глаза из-за непереведённого термина. Рад, что наши мнения совпали. Аналогичная ситуация думаю может возникнуть с термином Promise(s).
Я хочу привести выдержку из статьи на википедии о futures и promises:
Термин promise был предложен в 1976 году Дэниэлом Фридманом и Дэвидом Вайзом, а Питер Хиббард назвал его eventual. Похожая концепция под названием future была предложена в 1977 году в статье Генри Бейкера и Карла Хьюитта.
Термины future, promise и delay довольно часто взаимозаменяемы, однако далее описана разница между future и promise. Под future обычно имеется в виду представление переменной, доступное только для чтения, а под promise — изменяемый контейнер с одиночным присваиванием, который передаёт значение future. Future может быть определён без указания того, из какого promise будет получено значение. Также с одним future может быть связано несколько promise, однако присвоить значение future сможет только один promise. В остальных случаях future и promise создаются вместе и привязываются друг к другу: future — это значение, а promise — это функция, которая присваивает значение. На практике future — возвращаемое значение асинхронной функции promise. Процесс присваивания значения future называют resolving, fulfilling или binding. В некоторых источниках на русском используются следующие переводы терминов: для future — будущие результаты, фьючерс, также может означать преднамеченность; для promise — обещание; для delay — задержка.
Если отталкиваться от этого — promise в futures-rs, это любая функция, которая возвращает структуру реализующую типаж Future.
А в некоторых языках и библиотеках (в рамках одного языка/платформы) они ещё более перемешаны.
Например, в Java java.util.concurrent.CompletableFuture<T> является одновременно и future (представляющий собой асинхронный результат вычисления с кучей комбинаторов), и promise (с методами типа complete(T), completeExceptionally(Throwable)), а java.util.concurrent.Future<T> является историческим огрызком, который представляет собой некий асинхронный результат, который может быть проверен на завершенность/отмену, получен синхронным блокирующимся методом или отменён (если реализация поддерживает отмену и выполнены необходимые предусловия).
В Scala scala.concurrent.Promise[T] и scala.concurrent.Future[T] разделены, Promise[T]#future() возвращает связанный с данным promise'ом future.
В JavaScript future называется Promise, а методы promise'а (resolve() и reject()) передаются функции, которая передаётся конструктору этого Promise.
В общем, это две стороны одного концепта, которые не всегда разделяют. Имена классов выше кликабельны, если есть желание посмотреть на api.
Если отталкиваться от этого — promise в futures-rs, это любая функция, которая возвращает структуру реализующую типаж Future.
С этим я бы поспорил. Из описанного в статье, например, futures::oneshot() возвращает (Complete<T>, Oneshot<T>), где Complete<T> является promise'ом, а Oneshot<T> — future.
Введение в futures-rs: асинхронщина на Rust [перевод]