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

41–50 of 84 posts

Re: Futures for C++11 at Facebook

#41

Post by fugalh »

blakesmith wrote: post #37

I'm a huge fan of Finagle futures, which this project seems to draw a lot of inspiration from. My biggest challenge is actually the fact that Folly as a dependency is so heavyweight memory wise: I have trouble building anything on my laptop with 4 gigabytes of memory. Most of the Folly code is template code - I guess lots of template code leads to large memory compile time footprints? Anyway - great project. I'd love…

Yes, templates are expensive at compile time (memory and time both). folly/futures only depends on a few pieces of folly/, you may find that you can use the futures headers just fine. If building libfolly is the showstopper, you might be able to comment out all the non-dependent files.

Re: Futures for C++11 at Facebook

#42

Post by No1 »

fugalh wrote: post #18
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

E came out in 1997. From my perspective, Scala and C++11 are the backward ducks (unless you can point to something earlier using the Scala/C++11 nomenclature).

I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.

Re: Futures for C++11 at Facebook

#43

Post by learc83 »

damart wrote: post #36

Futures/promises seem like they're basically just a limited subset of FRP (Rx, RAC) observables/streams - such that they either "next" once and "complete", or "error" without "nexting". I suppose they also have caching built in, but that is easy to build on top of FRP.

Yeah, I think you're right on the money. Matt Podwysocki has a chart explaining how promises fit in to all of this but I can't seem to find it. Here's what he says in the RxJs documentation.

"One question you may ask yourself, is why RxJS? What about Promises? Promises are good for solving asynchronous operations such as querying a service with an XMLHttpRequest, where the expected behavior is one value and then completion. The Reactive Extensions for JavaScript unifies both the world of Promises, callbacks as well as evented data such as DOM Input, Web Workers, Web Sockets. Once we have unified these concepts, this enables rich composition."

Re: Futures for C++11 at Facebook

#45

Post by Serow225 »

fugalh wrote: post #9
hatred wrote: post #6

Can 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 f…

Since it seems like you're at FB, do you know if anyone's working on an equivalent of FB's Swift but for C++ instead of Java? If so, I'd love an email to express interest in such a thing. Thanks in advance!

Re: Futures for C++11 at Facebook

#46

Post by modersky »

No1 wrote: post #42
fugalh wrote: post #18

Earlier quoted context omitted.

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

E came out in 1997. From my perspective, Scala and C++11 are the backward ducks (unless you can point to something earlier using the Scala/C++11 nomenclature). I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.

It's much older than that. See

https://en.wikipedia.org/wiki/Futures_and_promises

The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.

Re: Futures for C++11 at Facebook

#47

Post by wtf_is_up »

millstone wrote: post #19

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 c…

Futures in Scala are composable, so this becomes:

    val upload = for {
      p  // do stuff
        case Failure(why) => // do stuff
    }
These will not happen concurrently unless the futures are declared outside of the for comprehension.

Re: Futures for C++11 at Facebook

#48

Post by millstone »

teraflop wrote: post #38
millstone wrote: post #35

Earlier quoted context omitted.

> If you want actions to take place atomically, then why make them asynchronous? This is usually up to the API you are using. You may not have a choice. > your code is inherently single-threaded and no locks are necessary Locks are necessary in the single threaded case. See my example: Pending.remove(todo).then({Completed.add(todo)}) Nothing prevents another operation from executing between the remove() and add() cal…

Sorry, maybe I was unclear. Let me try again from a different angle: It's up to an API designer to come up with a sane API, including sane usage of futures/promises only where it makes sense. In the browser world, futures or promises are an abstraction over some operation that doesn't block the UI thread, and therefore can allow some other work to happen in the meantime. In your example, if Pending and Completed prov…

That makes sense. Thank you for your thoughtful reply.

Re: Futures for C++11 at Facebook

#49

Post by obstinate »

dbattaglia wrote: post #39
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.

I think the language and framework are also important in deciding to use them or now. In modern C# with MVC/WebAPI it feels wrong to me to NOT use async/await/Task (the .Net version of Futures and Promises). For fairly little change in coding style you can get some big performance wins on IO code.

Unless you're writing pretty perf intensive code, part of me doubts you're going to see huge wins on something like async/await.

Re: Futures for C++11 at Facebook

#50

Post by Cakez0r »

Aleman360 wrote: post #28
forrestthewoods wrote: post #17

Earlier quoted context omitted.

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…

Microsoft uses "Task". I like that way better.

and also the aptly named "TaskCompletionSource", which would be the promise equivalent (using Facebook's terminology)
Post reply on HN