Futures for C++11 at Facebook
code.facebook.com
Futures for C++11 at Facebook
1–10 of 84 posts
Re: Futures for C++11 at Facebook
#2I'm totally on board with futures, IF your application needs to scale to the point that blocking, threaded computation is infeasible. However, I honestly don't think that's the case for most folk. Blocking, direct-call computation is way simpler than futures.
Re: Futures for C++11 at Facebook
#3Futures sounds a lot like Promises to me. Or am I wrong?
Re: Futures for C++11 at Facebook
#4Promises, C++ style?
Re: Futures for C++11 at Facebook
#5On a related note, MS has PPL on Windows:
https://msdn.microsoft.com/en-us/library/dd492427.aspx
Very similar to C#'s TPL.
And VS2015 has experimental support for async/await in C++: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-...
Re: Futures for C++11 at Facebook
#6Can someone explain to me what does it add over http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchro... and pros/cons ? Thanks.
Re: Futures for C++11 at Facebook
#7Futures sounds a lot like Promises to me. Or am I wrong?
Re: Futures for C++11 at Facebook
#8I'd be interested in seeing why instagram didn't implement the suggested user service as a batch process that populated some KV store. Online evaluation is great for guaranteeing up-to-date results, but the tradeoff is that you now have to bring up and maintain a fairly critical production service.
> The SU service fetches candidate accounts from various sources, such as your friends, accounts that you may be interested in, and popular accounts in your area. Then, a machine learning model blends them to produce a list of personalized account suggestions.
> This enabled us to reduce the number of instances of the Suggested Users service from 720 to 38.
Re: Futures for C++11 at Facebook
#9Can someone explain to me what does it add over http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchro... and pros/cons ? Thanks.
It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost futures are now more robust and/or more performant in 1.58.
Re: Futures for C++11 at Facebook
#10Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only...
There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention.
Agreeing on terminology is hard. :)
Edit: I think it's fine that Folly adopted the C++11 convention. I'm just whining in the open that that promise vs. future may never be agreed upon.