Чим відрізняється майбутнє від обіцянки?

Чим відрізняється майбутнє від обіцянки? (В Акка та Гпарс.)

Вони виглядають так само, як і блокують, і повертають значення майбутнього, коли викликається get, і обіцяє отримати результат майбутнього.

Я розповім про Akka / Scala, тому що я не знайомий ні з Gpars, ні з Akka / Java.

У Scala 2.10, що включає відповідну частину Akka у стандартному розподілі, a Futureпо суті є посиланням, яке лише для читання, на значення, яке ще потрібно обчислити. A Promise- це майже те саме, за винятком того, що ви також можете йому написати . Іншими словами, ви можете читати і з Futures і Promises, але ви можете писати лише в Promises. Ви можете отримати Futureасоційоване з a Promiseшляхом виклику futureметоду на ньому, але перетворення в іншому напрямку неможливе (тому що це було б безглуздо).

За вікіпедією , вони є тим же поняттям:

У галузі інформатики майбутнє, обіцянки та затримка відносять до конструкцій, які використовуються для синхронізації в деяких паралельних мовах програмування. Вони описують об'єкт, який виступає проксі для результату, який спочатку невідомий, як правило, тому, що обчислення його значення ще не завершено.

Деякі бібліотеки можуть вирішити назвати їх одним способом, деякі можуть вибрати інший. І кожного разу вони можуть бути реалізовані в різних смаках. Деякі бібліотеки можуть використовувати ці синоніми для розрізнення різних смаків. Хоча я б заперечував, що це поганий вибір (оскільки, очевидно, це бентежить людей), це посилання говорить про те, що в Scala це звичайна практика.

Як запропонував полум'я @ Птарієна, у Scala a Futureце операція лише для читання, а a Promiseдає можливість отримати результат (або збій) для операції, яку вона представляє.

Таким Promiseчином, A найкраще використовується кодом, відповідальним за проведення операції по поширенню результату, а A Futureвикористовується для викриття його на клієнтський код, який, в свою чергу, чекає результату. Але ще раз зауважте, що ця відмінність є специфічною для Scala і може бентежити сторонніх людей.

Я додам трохи сюди, тому що я працював із безліччю Futures in Java на пізньому терміні, але також маю досвід розвитку Scala / Akka. Ця відповідь здебільшого повторюватиме сказане, але вказуватиме на безліч реалізацій, які сьогодні широко використовуються у JVM.

По-перше, в оригінальному плакаті згадується використання get і blocking - будь ласка, ніколи цього не робіть поза тестами.

Коли я викладаю поняття FP та Concurrency в моїй теперішній ролі, я спочатку кажу студенту, що семантично обіцянки та ф'ючерси є синонімами, тому що, як споживач обіцянки чи майбутній api, розробнику не потрібно розуміти, що існують чи ЯКЩО існують семантичні відмінності - лише механіка поводження з ними без блокування IO.

Сказати, що майбутнє не може бути виконане, і що обіцянка може (наприклад, відповідно до шкали / акка / грати в apis), занадто спрощена:

Деякі майбутні майбутнє можна виконати Java8 тепер вводить CompletableFuture у стандартну бібліотеку.

Деякі обіцянки неможливо виконати Аналогічно, в API для обіцянок Play обіцянка не може бути виконана, але ReedeemablePromise може таким чином вводити різну семантику - навіть перебуваючи під парасолькою Typesafe. Крім того, API API для обіцянок може конвертувати зі скала-ф'ючерсами в обох напрямках - (F.Promise.wrap (майбутнє) або promis.wrapped ()).

Працюючи з технологією Typesafe на Java8, ви часто переходите назад і назад між ф'ючерсами / обіцянками просто тому, що один API більш кращий (Play Promise API здається кращим з лямбдами Java8). На Akka + Play + Java8 ви будете брати ф'ючерси у "Акторів" і обертати їх обіцянками, складати зворотні дзвінки та повертати їх з контролера.

Отже, як я кажу людям, коли я навчаю, обіцянки та майбутнє - це більш-менш синоніми.