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

61–70 of 84 posts

Re: Futures for C++11 at Facebook

#61

Post by electrum »

Serow225 wrote: post #45
fugalh wrote: post #9

Earlier quoted context omitted.

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!

Swift uses annotations (reflection) and generates bytecode on the fly. This fits much better with modern Java development practices and tooling than source code generation. Is such a thing feasible C++, especially in an idiomatic way? Or perhaps I am misunderstanding your question.

To my knowledge, our C++ Thrift code is here: https://github.com/facebook/fbthrift

(I work on Presto and occasionally Swift at Facebook, but am not at all familiar with modern C++)

Re: Futures for C++11 at Facebook

#62

Post by pron »

obstinate wrote: post #23
pron wrote: post #16

Earlier quoted context omitted.

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

Fibers are fine as an idea. But all the C++ implementations I'm aware of require the programmer to mark up their code for cooperative scheduling. That's a non-starter for me.

So writing their code completely differently is a less-costly alternative?

Re: Futures for C++11 at Facebook

#63

Post by jnordwick »

Total strawman on the code example. They don't really need the mutex and all the complexity, but they add it so they can overstate their point -- make the most complex code you can and compare it to a simple example you code. Blah.

Re: Futures for C++11 at Facebook

#64

Post by nimrody »

wtf_is_up wrote: post #47
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.

I guess this should be

     u
right?

Re: Futures for C++11 at Facebook

#65

Post by obstinate »

pron wrote: post #62
obstinate wrote: post #23

Earlier quoted context omitted.

Fibers are fine as an idea. But all the C++ implementations I'm aware of require the programmer to mark up their code for cooperative scheduling. That's a non-starter for me.

So writing their code completely differently is a less-costly alternative?

If I compare the three alternatives:

    - Standard blocking code in OS threads.
    - Future-based code.
    - Coroutines with explicit annotation.
The latter is probably only viable for very large organizations in terms of engineering cost. The other two are doable for smaller organizations.

Re: Futures for C++11 at Facebook

#66

Post by rattray »

forrestthewoods wrote: post #17
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…

I've always found "promise" intuitive personally; it returns a guarantee about a future action. "Future" gives me a vague idea that it has to do with something later, but isn't great.

Learning these terms isn't that tough, either. I don't find "promise" any less intuitive than "statement", "expression", "parameter", or "argument". I'm just used to the latter ones.

Re: Futures for C++11 at Facebook

#67

Post by yelnatz »

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.

That term actually makes the subject much more understandable.

Re: Futures for C++11 at Facebook

#68

Post by xyzzy123 »

jasonzemos wrote: post #53
iambvk wrote: post #52

Am I the only one who thinks ".then(...)" code is also unreadable? Composability with ".then(...)" looks like a workaround for C++ limitations. Why can't we have this instead: fooAsync(input) { //... USING_B_THREAD_POOL //... USING_A_THREAD_POOL //... USING_B_THREAD_POOL //... } What are the disadvantages?

.then() is a hack as much as the entire async paradigm is a hack to make up for the weight of OS-supported threads used in their intended way. We have to step back and ask: what is the ideal mode of development? What does one want to do but can't? The ideal answer is to continue developing in the traditional, stackful, RAII-made-easy way where the operating system can provide a suitable natural API and runtime enviro…

Fibers which could do async IO coded in a blocking style (co-operatively tasked) would rock so hard that one day it has to work without sucking...

Re: Futures for C++11 at Facebook

#69

Post by pron »

obstinate wrote: post #65
pron wrote: post #62

Earlier quoted context omitted.

So writing their code completely differently is a less-costly alternative?

If I compare the three alternatives: - Standard blocking code in OS threads. - Future-based code. - Coroutines with explicit annotation. The latter is probably only viable for very large organizations in terms of engineering cost. The other two are doable for smaller organizations.

Can you explain why? Futures seem to be much more intrusive than the other two.

Re: Futures for C++11 at Facebook

#70

Post by kriro »

gohrt wrote: post #26
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…

A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

That's exactly what a "future" is in trading terms. I think the problem is conflating domains. I'm pretty sure most people will interpret future as "the future" and not as a "future contract".
Post reply on HN