Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Futures for C++11 at Facebook

code.facebook.com

Post reply on HN
Print view View original

11–20 of 84 posts

Re: Futures for C++11 at Facebook

#11

Post by vvnraman »

Excellent library and writeup !!

This is very similar to HPX, the general purpose C++ runtime system for parallel and distributed applications by the Stellar Group - https://github.com/STEllAR-GROUP/hpx.

I recently saw the excellent video presentation by Hartmut Kaiser on this https://www.youtube.com/watch?v=5xyztU__yys and a lot of concepts in folly futures are quite similar. However the most striking thing in HPX was that all the building blocks are serializable, and the presenter mentioned that it is so because you could serialize and move a thread to a different machine and run it there.

Re: Futures for C++11 at Facebook

#14

Post by fugalh »

salibhai wrote: post #3

Futures sounds a lot like Promises to me. Or am I wrong?

Yes, the two terms are unfortunately both synonymous (comparing different implementations of the pattern in different languages), and usually have specific meanings in the context of any given implementation. Often, as here, Promise is the write handle and Future is the read handle.

Re: Futures for C++11 at Facebook

#16

Post by pron »

obstinate wrote: post #2

I'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.

Or use fibers (lightweight threads) and enjoy the best of both worlds: simple, blocking code with the scalable performance of async.

Re: Futures for C++11 at Facebook

#17

Post by forrestthewoods »

chadaustin wrote: post #10

Rats, 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 j…

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do.

The following is my favorite interview response of all time.

Q: what's a quaternion? A: I don't know... But I bet it has four parts.

Genius! An honest answer followed by a wise educated guess. Now, what's a future and what's a promise? How can you remember the difference? Good luck!

Those terms should be retired forever.

Re: Futures for C++11 at Facebook

#18

Post by fugalh »

chadaustin wrote: post #10

Rats, 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 j…

Scala also takes the same way C++11 does, and to my mind it makes more sense this way. So from my perspective Javascript is the backward duck here. I agree it would be nice if we could all just settle on something

Re: Futures for C++11 at Facebook

#19

Post by millstone »

I've never programmed seriously with futures, and I'm a little apprehensive.

For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order.

> It is more efficient to make service A asynchronous, meaning that while B is busy computing its answer, A has moved on to service other requests. When the answer from B becomes available, A will use it to finish the request.

What if the first request is "set sharing permissions to private" and the second request is "upload this compromising photo?" Obviously it would be bad to process these out of order. How is this handled?

Post reply on HN